>MS was sued just over this. The girl that sued them was correct.
>MS FoxPro programmers hosed up here, they certainly have a hard coded
>century setup instead of getting the century from the system. They should
>have lost that lawsuit but the judge declared it worked as documented.
>I know because I had to write a function that did just that - and I easily
>got the century from the current system date - foxpro has the ability to
>get it - the MS programmer just had no vision.

Carl,

You are way off base with this. There is nothing that disallows year 2000 stuff in any version of fox all the way back to FoxBase +. I wrote a system using foxbase+ back in the early 80's for a court system that required dates in 1800, 1900, and 2000 and it worked flawlessly.

Anyone who used these products and did not address the year 2000 issue in THEIR own code is guilty of bilking their clients, not Microsoft or Fox Software.

And those very same people are probably still not using the SET CENTURY TO ... ROLLOVER ... correctly. They are very likely still showing their users ambiguous dates on screen and in reports.

Guess what, even if the user forgets to type the century in if you show them all four digits they will see it and know it and can fix it, but if you show them only two digits then the user has no way of knowing what the century is even in VFP with the new commands.

The judge dismissed that lawsuit because it had no merit and it did have NO MERIT. It is still baseless. Multiple centuries can be handled using Fox code in all versions of fox that I have used and I started with fox in FoxBase+.

The issue of multicentury stuff with every version of fox prior to VFP is simply that the programmer has to pay attention to the handling of dates. Even in VFP using the rollover option the programmer show only two digit years and cause the users to be unable to determine what the real date is.