Hello Gilles!
Sunday December 22 1996 06:39, Gilles Beauregard wrote to Renald Loignon:
 rl>> Even with "SET CENTURY ON"???????
 GB>  We don't talk that part. With talk about Y2K bug fix.
But that IS the Y2k thing, because without it, the program can't work 
anyways, because right around the turn, its going to require entering data 
BOTH ways. Nothing else will work.
 GB>> In conclusion I have to re-write ALL application already done.
If it was not written right in the first place that is true.  But the changes 
needed are VERY small.  Just make the fields for dates larger, and set 
century on.  That is ALL that is needed.  Generally just editing some 
screens, and changing ONE line of code.
 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.
 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. My neighbors old employer use FoxPro as accountant
 GB>  application. Their is nearly 25 employees using the application with
 GB>  a lot of computer in the network. And their is a lot of other in
 GB>  the same situation. Now, it's the 4 fourth programmer in duty, and
 GB>  the precedent don't let a lot of documentation on the application
 GB>  they do for the company. What will append?
Thats STILL not a bug in foxpro, but in the programs that were written by 
these programmers.  Foxpro does exactly what its told to do.  For things to 
be Y2k ready, they CANNOT make assumptions about dates, and that is NOT the 
issue, but rather that the program can tell the difference between 1900 and 
2000.
 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
 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.
Nope, NOT a bug.  The only bug in in programmers thinking that the writers of 
the development system are supposed to address all the issues that THEY 
forgot. Most of the application does NOT need to be rewritten.  Even the 
stuff I wrote 10 years ago can be fixed with just a few lines of code.  All 
that is needed is to fix the date fields and turn on century awareness.  
Which BTW, is and HAS been a setting for years.  To tell foxpro to assume all 
dates are prefixed with 19 or allow the century to be entered.  This is NOT a 
bug, a bug is something that does not work as designed.  Foxpro work 
precisely as it was designed in this instance.  You may not agree with the 
design, but your choices are to go to something else, or work within the 
design of the product chosen.  And if they don't have source, they are dead 
anyways, since to recompile under a new version that made different 
assumptions would require the source code.
 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...
 GB>  Probably 99% of the application writing in FoxPro or other
 GB>  DBASE application was for day to day aplication, accounting for the
 GB>  majority, and if you have to write Julius Cesar or Napoleon
 GB>  accountant, you work on a small date range, 5-10 year in the past
 GB>  for the history and 1-5 year in the future for the planification. For
 GB> all my working live, I NEVER NEVER work on date past that range.
Interesting, since I SELDOM work within a range that restricted.  I have 
almost NEVER needed dates only within that short of a range, as birthdates 
are often 25 or more years in the past.  Any programmer that has not been 
writing things to be y2k aware for at LEAST the last 5 years, does not 
deserve whatever he is getting paid.  This is an issue we have known about 
for years, and the ability to deal with it has been around as long as foxpro 
has been.  Even foxbase is y2k ready.
 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
 GB>  Reworking. When you are force to reworke your job because of
 GB>  a NOT PLAN EVENT, you or the application was a bug.
Your right, the application that was written in foxpro (not foxpro) has a 
bug, because is was NOT written to handle the dates that are needed.  Support 
for foxpro for dos is going to totally end soon anyways, so anything that is 
going to need to continue to run past the year 2000 needs to be moved 
anyways.  But your right, when the programmer KNEW that the event was coming, 
its a but in the programs he wrote.  MS (and fox software before them) knew 
about what was coming and dealt with it, and even suggested that century but 
turned on, but many ignored what they were told, and then don't like it when 
things work exactly the way they were designed.  So you can cry all you want, 
but its not going to change the fact that the bug is in the programs WRITTEN 
in foxpro, not in foxpro itself, since foxpro understands the difference 
between 1900 and 2000, its just that the programmer didn't think ahead, that 
NOT the fault of foxpro.  And if the companies don't have source for these 
programs, they will just have to get one of the decompilers for foxpro (I am 
assuming that the developers of the packages in question are no  longer 
around) to recover the source to make the FEW changes needed to support the 
new century.
 rl>> above.  That's a LOT more than can be said for many
 rl>> other development platforms...
 GB>  Anyway, a lot of job for the programmer for the next 3 years.
Not for those who wrote their programs right in the first place.  But just to 
clarify, when they talk about the Y2k bug, they are talking about systems 
that can't even TELL the difference between 1900 and 2000 because they don't 
even STORE the century portion of the date, and foxpro just does NOT fit into 
that area.
Cy
Internet: Cy.Welch@pmra.gigo.com
          cwelch@calweb.com
Web Page: http:/www.calweb.com/~cwelch/
FTP  DIR: ftp:/ftp.calweb.com /users/c/cwelch/
... 80486 100Mhz. Don't you smell something burning?
--- GoldED/386 2.50+
---------------