Allo! only 1142 days till YEAR 2000, are you ready?
 rl> The people using them will have to face the fact that 
 rl> regardless of the language and platform, these 
 rl> applications will eventually have to be scrapped and 
 rl> replaced.
 Why, for your pleasure, Bill Gates own, or the Customer pleasure.
 If you have an application working fine for a while and
 you have master it after a lot of study, why you scrapped it.
 Cause, it's only "a 2 digits" for the year and the programmer
 don't figure that. Sorry.
 GB> My neighbors old employer use FoxPro as accountant
 GB> application. Their is nearly 25 employees using the application
 rl> 1) Run FOXDOC on the application, and print the results.
 rl> 2) From that machine-generated documentation, identify 
 How much? Who paid? You, me, my employer, the government, who will paid?
 
 rl> In act, even if the original programmer(s) had left 
 All programmer let a full set of documentation behind him. You are
 a dreamer.
 rl> documentation, I would probably favor using FOXDOC to
 rl> find the date fields for myself...
 rl> Send them to me if they don't trust their own staff (or available 
 rl> consultants) to do a good job of it.  I've been doing 
 rl> dBASE/FoxBASE/Foxpro stuff since the days of dBASE III 
 rl> (non-plus).
 OK, I understand. You looking for job to be done. The kind of guy,
 who never see a bug, but a good occasion to use the billing pad
 and fix and/or improve the application. At 50$ or so by hour.
 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.
 rl> Nothing prevented people from using "SET CENTURY ON" 
 rl> in Foxpro, FoxBASE and even dBASE III+ programming, as 
 Why I must use 4 digits when 2 is sufficient for my application.
 For myself I can easyly figure we talk about year 2000 when we are
 in 1996, not talking about 1900.
 Foxpro designer has only to add a new feature. ASSUME NEXT CENTURY.
 When you are near the end or the beginning of the century, you must
 ASSUME the next of the precedent century, that it's. Probably
 not a big feature to implement into Foxpro or other language.
 I see a lot of more esoteric feature.
 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
 You talk about application, I talk about FoxPro. Your application
 can be YEAR 2000 ready with FoxPro who is NOT YEAR 2000 READY.
 GB>  Reworking. When you are force to reworke your job because of
 GB>  a NOT PLAN EVENT, you or the application was a bug.
 rl> The question is, why call it a __Foxpro__ bug?
 Because it's a bug.
 rl> This is part of why, contrary to you, I (and many 
 rl> others as well) do not see a big problem in making 
 rl> Foxpro programs Y2K-ready, as long as the source is 
 rl> available.
 As long as the source is available, the BIG QUESTION?
 See you
 Gilles@biwi.qc.ca         Moderator  2000
--- Maximus 3.01
---------------