I did meet the similar behavior when converting DOS application to VFP a couple of years ago. For date DOS Foxpro accepted delimeters like regular "/", but also "\" and some others. So original DOS code contained various delimeters. If I recall it correctly, I compiled it in VFP without any errors, but got error on run time. So I had to replace all delimeters to "/".
Looks like you meet the similar problem. Try to replace "/" in your line:
STORE {^2200-01-01} TO ldEndDate
Seems it may help.


>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