RB>> Yes, thankfully FoxPro is ready for the next millenium.  In the
 GB>  It's what I assume until yesterday. I do some Y2K check on a flat
 GB>  file. Only the basic file with some date field and some index
 GB>  in that date field.
 GB>  I check what append when you enter 00/12/12 as the date. And
 GB>  FoxPro assume it's 1900/12/12, not 2000/12/12.
Even with "SET CENTURY ON"???????
 GB>  In conclusion I have to re-write ALL application already done.
How about doing these two relatively steps:
1) Add "SET CENTURY ON" at the beginning of all the programs
2) Change your scrren layouts to allow two more spaces for all date fields
Presto!  Your application is _NOW_ Y2K ready.
 GB>  If FoxPro was really a true Y2K ready package, it's assume
 GB>  2000 when you write 00 in a 2 digits date field.
That's only YOUR definition of being "Y2K ready".  Most people's definition 
is not that restrictive (or quirky).  After all, according to YOUR 
definition, it would have been impossible to support dates before the year 
1901 in the old dBASE applications, unless you expect Foxpro to read the 
user's mind in order to decide when "00" REALLY means year 0, when it means 
1900, and when it means 2000...
 GB>  I do the check in 2.6x DOS of FoxPro. Anyone can check if the
 GB>  same Y2K bug with the lastest version?
Call it "bug" if you insist.  Nevertheless, your existing Foxpro applications 
can be made Y2K-compliant with comparatively little reworking, as outlined 
above.  That's a LOT more than can be said for many other development 
platforms...
--- GoldED 2.50+
---------------