>Any thoughts on how to handle existing code to solve
>the year 2000 problem.
>

Ajay,

Microsoft's official position is that their products have always been Year 2000 compliant and that the problem is mainly a "mainframe problem". I think this statement is a little broad myself.

I use both VFP 3.0 and FPD 2.6, and hope (I will test this) that all my code is Year 2000 compliant. I only use the built in Foxpro functions to manipulate dates (which are stored using a 4 digit year). I would be interested in hearing from people on this issue also. Which version of Foxpro or FoxBase used only 2 digit date fields (inherently)?

I am also interested in hearing why anyone would have circumvented Foxpro's built in 4 digit year by writing "optimized" code that used only 2 digits.

If anyone is interested in an eye-opening test. If you are running Win 3.1 or earlier, set the date/time to Dec 31, 1999, 11:58pm. Shut off the PC, wait 4 or 5 minutes and then turn it back on. In testing 60 pcs at the hospital, only those with Windows 95 correctly rolled over to year 2000, regardless of the age of the pc. Granted, this is not a major problem since you can manually set the date back to 2000, but us systems people will have enough problems on Jan 1, 2000 to deal with without all the pc clock calls.

Sorry for the rant and shifting your thread off it's original focus...