Want to confirm this behaviour as I have not been able to conclusively find another bug but this seemed to fix the problem...anyone confirm?

Situation: when doing a coded SELECT statement with a lower and upper date range, in order to keep the SELECT fairly generic, if there was no upper date range supplied, I had code like this before the actual SELECT:

IF EMPTY(ldEndDate)
STORE {^2200/01/01} TO ldEndDate
ENDIF

then I would issue the SELECT. On my Development machine, would never fail. On the server, it randomly failed and on the very same report, would produce different errors when re-running the same report ie. an error would show up on page 1 at one point and then page 3 when run again or sometimes no error at all.

I finally tracked down that on the server machine when the form ran (that contained some options, none of them text box or I would have seen it), that SET CENTURY was off there whereas on my Dev machine, it was always on.

So I could set it on but I really wondered why it would matter since the date above is in code and it is supposedly in an unambiguous format. I tried setting CENTURY on and off and compiling the code and although I cannot read the pseudo-code, there is a difference in the compiled code when compared byte by byte. I don't think that SET CENTURY would ever be off on my Dev machine so it should always compile to the same but maybe there is also a difference running the code if the run-time machine has SET CENTURY OFF. Again, I would not have though so as the variable created should hold the same date regardless of the setting of SET CENTURY.

Anyone run into this? Since the report is highly-critical for this client (they sell based upon the numbers generated), I would like to confirm that this was indeed the problem. BTW, I replaced the above code with:

STORE DATE(2200,01,01) TO ldEndDate

and this *seemed* to fix it. I might even rewrite the SELECT code to only include the upper range if the var is not empty.

Thanks,
Albert