>If it's changed in the code, it will run. But... changing STRICTDATE is a bandaid. It just
>hides the issue. The real fix is to change the way the code is written to define the date
>properly.


It is not improper, Craig.

The date is defined properly within the STRICTDATE setting. It is not an improper encoding, nor is it an issue outside of this particular environment where STRICTDATE was suddenly and unexpectedly set to a non-default value outside of explicit developer direction / intervention.

From VFP9's help:
"SET STRICTDATE TO 0
Specifies that strict date format checking is off.
This setting provides compatibility with earlier versions of Visual FoxPro.
0 is the default setting for the Visual FoxPro runtime and ODBC driver.
When STRICTDATE is set to 0, invalid Date and DateTimes evaluate to the empty date."


>The build error message shows you want to do.

Personally, I'd track down the DC admin and say "Hey. What's up?"

The bottom line here:
A system that's been working for years was clobbered by some introduced setting that wasn't properly tested on a few users and developers before being pushed out unilaterally. It is causing developer (and presumably user) downtime, compile issues, and is the direct result of a categorically mishandled vetting procedure. This issue needs to be addressed before other unexpected issues start cropping up through a similar nonchalance policy.