GB>  Allo! from down the street!
En effet, et plus encore que tu ne le penses... (rhl@cam.org).
 GB>  For mine, I don't have have any problem to re-writen ALL application
 GB>  when you are a the turning of the century, for the pleasure of it,
 GB> shame. But how many application are now orphan, whitout source to work
 GB>  on it.
The people using them will have to face the fact that regardless of the 
language and platform, these applications will eventually have to be scrapped 
and replaced.
 GB> My neighbors old employer use FoxPro as accountant
 GB> application. Their is nearly 25 employees using the application
 GB> with a lot of computer in the network. And their is a lot of
 GB> other in the same situation. Now, it's the 4 fourth programmer
 GB> in duty, and the precedent don't let a lot of documentation on
 GB> the application they do for the company. What will happen?
1) Run FOXDOC on the application, and print the results.
2) From that machine-generated documentation, identify the date fields (and 
date memvars) used, and the program modules that use them.
3) Locate all SAYs and GETs that use these date fields/memvars, and adjust 
screen/printer coordinates as needed.
4) Re-compile, test, and test AGAIN, and then test SOME MORE.
In act, even if the original programmer(s) had left documentation, I would 
probably favor using FOXDOC to find the date fields for myself...
Send them to me if they don't trust their own staff (or available 
consultants) to do a good job of it.  I've been doing dBASE/FoxBASE/Foxpro 
stuff since the days of dBASE III (non-plus).
 GB>  A bug, it's a bug. When you are force to REWRITE MUST of the
 GB> application because of a NOT PLAN EVENT, who can predict their is a
 GB> new century in 3 years from now after all, IT'S A BUG.
Nothing prevented people from using "SET CENTURY ON" in Foxpro, FoxBASE and 
even dBASE III+ programming, as far back as 10 years ago.  If they did not 
bother using the feature back then, when it was *_ALREADY_* available, why 
should we blame the tools, rather than the users?
 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
 GB>  Reworking. When you are force to reworke your job because of
 GB>  a NOT PLAN EVENT, you or the application was a bug.
The question is, why call it a __Foxpro__ bug?
Are you aware of the PHYSICAL storage format of date fields in DBF files, at 
least since dBASE III?  Regardless of "CENTURY ON/OFF", and regardless of 
"YY/MM/DD", "DD/MM/YY", "MM/DD/YY", or any other date setting supported by 
any xBASE application platform, the physical format is:
    YYYYMMDD
Yep!  The century has "ALWAYS" been stored in the data files!  When using 
2-digit year fields for data entry, Foxpro (and even dBASE III before it) has 
always stored those dates as "19YYMDD".  That way, when a programmer decides 
to switch to "CENTURY ON" and longer date fields on screens and reports, the 
existing data is ALREADY compatible!
This is part of why, contrary to you, I (and many others as well) do not see 
a big problem in making Foxpro programs Y2K-ready, as long as the source is 
available.
--- GoldED 2.50+
---------------