Allo! from down the street!
 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.
 rl> Even with "SET CENTURY ON"???????
 We don't talk that part. With talk about Y2K bug fix.
 GB>  In conclusion I have to re-write ALL application already done.
 rl> How about doing these two relatively steps:
 rl> 1) Add "SET CENTURY ON" at the beginning of all the programs
 rl> 2) Change your scrren layouts to allow two more spaces 
 rl> for all date fields
 rl> Presto!  Your application is _NOW_ Y2K ready.
 For mine, I don't have have any problem to re-writen ALL application
 when you are a the turning of the century, for the pleasure of it, shame.
 But how many application are now orphan, whitout source to work
 on it. My neighbors old employer use FoxPro as accountant
 application. Their is nearly 25 employees using the application with
 a lot of computer in the network. And their is a lot of other in
 the same situation. Now, it's the 4 fourth programmer in duty, and
 the precedent don't let a lot of documentation on the application
 they do for the company. What will append?
 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.
 rl> That's only YOUR definition of being "Y2K ready".  Most people's 
 rl> definition is not that restrictive (or quirky).  After 
 A bug, it's a bug. When you are force to REWRITE MUST of the application
 because of a NOT PLAN EVENT, who can predict their is a new
 century in 3 years from now after all, IT'S A BUG.
 rl> all, according to YOUR definition, it would have been
 rl> impossible to support dates before the year 1901 in 
 rl> the old dBASE applications, unless you expect Foxpro 
 rl> to read the user's mind in order to decide when "00" 
 rl> REALLY means year 0, when it means 1900, and when it 
 rl> means 2000...
 Probably 99% of the application writing in FoxPro or other
 DBASE application was for day to day aplication, accounting for the
 majority, and if you have to write Julius Cesar or Napoleon
 accountant, you work on a small date range, 5-10 year in the past
 for the history and 1-5 year in the future for the planification. For all
 my working live, I NEVER NEVER work on date past that range.
 
 GB>  I do the check in 2.6x DOS of FoxPro. Anyone can check if the
 GB>  same Y2K bug with the lastest version?
 rl> Call it "bug" if you insist.  Nevertheless, your 
 rl> existing Foxpro applications can be made Y2K-compliant 
 rl> with comparatively little reworking, as outlined 
 Reworking. When you are force to reworke your job because of
 a NOT PLAN EVENT, you or the application was a bug.
 rl> above.  That's a LOT more than can be said for many
 rl> other development platforms...
 Anyway, a lot of job for the programmer for the next 3 years.
 gilles@biwi.qc.ca       Moderator 2000
--- Maximus 3.01
---------------