- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It will only work if @DateFormat is a format that IsDate can convert back from, and possibly only if @DateFormat matches the default system format (not an MSSQL programmer, but that is how Oracle would do it).
Admin
Come on, Joe, show some guts. Ditch the condition. You know that it's pointless, and even if it had some weird effect, the TO_CHAR call will always produce a valid date if the input is a valid date. It's in the bloody table definition!
Admin
Of course there's a heck of a lot more to a CR report than simply the query which returns the rows to be reported. I'm curious how Jon implemented everything, fonts and all, in a SQL stored procedure.
As a meta-comment, the text tells us the company eventually hit the limits of CR augmented with custom development. So they wanted some reports that needed more capability / magic. OK, that's not unreasonable on its face. So their solution to their problem is to reimplement stuff verbatim that CR is obviously already doing just fine with. WTF?
Admin
Exactly. I recently heard a story about a military commander by Napoleon (I think? ) because he was following orders too literally. Some people forget they have a head and it's not only for eating.
Addendum 2022-06-09 08:17: *commander punished by
Admin
I believe [it has been years] that the range of what the variable can physically hold, and what IsDate will return true for is DIFFERENT.
Admin
Exactly - even if the instructions are re-implement in other system/language/tool, I would still generally feel free to do things like eliminate things I was confident are no-ops, unreachable code, etc.
There is some wiggle room between let's not change the algorithm/procedure because we don't want to introduce any gotchas into a process which might already contain bugs we don't understand and being COMPLETELY brain dead about it.
Admin
ANSI escapes embedded as strings, and lots of case statements used to apply said formatting :-)
Don't laugh I have seen it.. still causes nightmares.
Admin
Hmm, I guess I can see the point in leaving in the existing functionality - after all this might do something clever like strip off the time portion of the date/time.
The fact that Crystal Reports and SQL are likely to handle the string/date conversions differently makes the point meaningless - you still need to know what is happening and what is supposed to happen.
Admin
Hmm... won't those variables just be null so this is just a real cludgy isnull check?
Admin
Years ago, I encountered a project where the "do it just like the previous" command actually made sense. The old system was built on a family of computers that had gone out of production, and were nearly out of support. The orders were to port the exact functionality, bug-for-bug compatible, to a new generation of computers. The reason was that the workers were used to work-arounds the old system needed. The saving grace was a requirement for an exhaustive list of bugs found, that were used to define improvements in the new system in the follow-on contract. The second contract was fast and profitable, with a detailed road-map prepared by the developers.
Admin
I wonder how often the people who ask for this sort of porting / etc. really meant "literally every single step must be identical" rather than "with the same input, the output must be the same".
Admin
I think everyone is assuming that because it say this is a "report", it is going to some non-processable output (like paper or a pdf file). It is possible that the report is being loaded into Excel. In which case the value loaded for a Datetime will be significantly different than one that has been converted to Text (depending upon the actual format being output and the formatting of the cell in Excel).
Admin
Sounds like a very good compromise!
Admin
Depending on the code quality, these two conditions may be effectively the same. Especially when there is no formal criterion for what counts as "output must be the same", so the only way to preserve the output accurately is not to change any logic that might, possibly through global side effects, affect the result.
Admin
Fair point, although I wasn't thinking of whether it's wise to not change the (detailed) logic, but whether the people demanding that as such meant "really keep all the steps exactly the same", and whether they just meant "make the output be the same", assuming they only have the output to look at.
Admin
I would be almost certain its "make the output be the same", because its pretty unlikely a end user is going to even be aware of the implementation details, and nobody on the software development / IT side would want to do a "brain dead" import of a process designed for a different system into a new one, EXCEPT because they were seeking to avoid risk related to not understanding some aspect of the algorithms, mistakes included, in the current implementation.
Reality is when doing something like this you are going to have to compare the outputs anyway because there is a good chance as some pointed out that crystals date/string functions don't have exactly equivalent behavior to their TSQL (or whatever dialect) counter parts used in the stored procedures. Its rather unlikely a direct 1:1 function name mapping and syntax massage is really going to replicate the original; some changes will certainly be required unless its all a lot more trivial than summary makes it sound.
Admin
You get that with serious numeric code, where reordering things can make a subtle difference to how numeric error is controlled. (You're OK when multiplying things, as those can be reordered, but additions and subtractions are a great deal trickier than they appear at first glance.)