• some guy (unregistered)

    On some level, they got lucky to catch this bug, because it roughly occurs only on one day out of four years. On the other hand, I suppose they always run their little report on the last day of the month, so it was bound to happen?!

  • Hanzito (unregistered)

    Crystal Reports, and a production database we couldn't touch with different settings than the test/development instance. What an absolute waste of time that was.

  • John Melville (unregistered)

    To be fair, though,

    This is a bug that is only going to show up for one day every four years.

    That is pretty good work by TDWTF standards.

  • A nunny moose (unregistered)

    Years ago I had to work with Crystal Reports, or to be more precise, a Delphi component wrapper for Crystal Reports. I never found out if the issue was with CR itself or the wrapper, but the damn thing leaked memory like there was no tomorrow.

    Now what I had to create was an app that run several reports in succession, so I ended up creating a list of reports, copy that file, and feed it into the app that ran 10 reports (and removed them from that copied file), launch another instance of the app, close the current one, and keep going until all reports had been run.

    Was that a terrible, filthy hack? Yes. Did it work? Also yes. Was I happy about any of it? Not at all. If it hadn't been for Clarion I'd call CR the most awful software I ever had the misfortune of having to work with.

  • John (unregistered)

    The logic for extracting parts of the date doesn't even make sense. It's obvious that the date must be formatted like "yyyy/MM/dd hh:mm:ss. In that scenario, the first four characters are the year. Sure. Then you start at index 5 and take two characters for the month. Ok, sure. Then you start at index seven, which is the second "/", and take two characters for the day. That gives you "/x" where x is the first digit of the day. Hour starts on the second character of day. Minute starts on the first character of hour, so minute is populated with hour instead. And second starts on the first ":" between hour and minute, so it gives you ":x" where x is the first character of the minute.

  • Darren (unregistered)

    Things like Crystal Reports - and the myriad of low-code / no-code 'solutions' - are actually alright for doing very simple things. The problem is that businesses see the simple thing and decide that "it'd be good if it could also do...' too.

    Which makes it that bit more complicated and beyond the real scope of what CR et al. can do. That in turn means that weird hacks come into play.

    Repeat this a few times and you end up with some obscene, fragile behemoth that no-one really understands (because Jeff who originally wrote it left years ago) and that no-one really wants to go near - but which has become absolutely business critical.

    Then the sunk cost fallacy comes into play and rather than just bite the bullet and rewrite it in something more appropriate, more and more bodges and hacks are applied - usually under duress by the poor soul charged with making the changes.

    It often takes a change in management - or a catastrophic failure - to force the retirement of said solution. A penny not spent today means a dollar spent tomorrow.

  • Mpripper (unregistered) in reply to John

    I assume the date is formatted "yyyyMMddhhmmss" and the Mid function is called like "starting with the 5th character take 2 characters", because 0-indexing is too complicated for end-users

  • (nodebb)

    Date handling code is difficult to write all 32 days of the month.

  • (nodebb) in reply to A nunny moose

    Sounds more like the Delphi wrapper was not disposing those COM objects correctly. We had to use CR in production as well, I wrote the C# interop wrapper back then because there wasn't anything available and my service produced hundreds of reports per day and didn't need to be restarted ever. Our server maintenance schedule was back then monthly, so any memory leak would have been super obvious, even a small one. Then again, who knows, CR was a very inconsistent black box (especially the performance was all over the place), so maybe I just got super lucky back then.

  • (nodebb)

    Leap years and DST... always lurking with trouble. We can't do much about leap years, but can we at least eliminate DST in our lifetimes? Sheesh.

  • John (unregistered) in reply to Mpripper

    Ok, that makes sense. There doesn't seem to be any way for it to work if Mid takes starting index and length, but it works if it's starting position.

  • DML (unregistered) in reply to RandalSchwartz

    It has been tried several times before, and every time it has, people start complaining about it getting dark too early or some other issue.

    It's become one of those "damned if we do, damned if we don't" situations.

  • MRAB (unregistered) in reply to John

    Those string functions are clearly borrowed from Basic, though without the final '$'. Basic had Left$(...), Mid$(...) and Right$(...) (well, more usually, LEFT$(...), MID$(...) and RIGHT$(...)) and strings indexes were 1-based.

  • matt (unregistered)

    Another one of those tools that LET (not lets). The relative clause describes the tools, not the one.

  • (nodebb) in reply to RandalSchwartz

    When I saw the error message I just knew it would be a leap year issue.

    Leap years and DST... always lurking with trouble.

    And time zones!

Leave a comment on “Leap to the Past”

Log In or post as a guest

Replying to comment #679879:

« Return to Article