>>This may be a little elementary for this forum but we have a couple of Foxpro2.6 and Foxbase applications and are concerned about Y2K. What would be the main areas to focus? I have been told to Set Century On and change date fields to the appropriate length. Is that all there is to it?
>
>NO, you must take the following into account:
>
>If you have a date field on a screen where the user types in the date; the user
>might leave off the century. If your PC has the date set to 2000 or later, and the user does NOT type in the century, FPW will supply 19 as the century EVERY SINGLE TIME. This is the basis of the lawsuit filed against MS.
>
>I solved it my gettting the field from the screen and comparing the century entered against the system date and when they did not match, I asked the user what century they wanted to use. This allows the user to enter dates from the past - say when it is Jan 2000 and the user is entering dates for 1999.

A lot of people (including me) have "rolled their own" valid function for use in FP 2.x which simulates VFP5+s SET CENTURY ROLLOVER. It's fairly simple: when you get to the valid, the date's already been expanded by Fox, but you check whether it's less than a certain date (which you may have #DEFINED or hard-coded into the valid routine or whatever), and if it's less than that date, bump it up from 19xx to 20xx by adding 100 to the year. (Or by GOMONTH(dateparm, 1200). :)

The only failing of this approach is that the user may enter 2/29/00 (a valid date if you're interpreting 00 as 2000, but not 1900). FoxPro refuses to accept this date as valid, and won't even get to your valid routine. There was clever code in a March/1998 FoxPro Advisor article for handling this situation.

HTH,