Jim,

sure this helps. Main concern here in my company was do we have to re-write existing FPD/FPW 2.6 apps in VFP - it seems that writing a custom date validation with 'set century on' could be suficient. Thanks so much,

Srdjan


>Srdjan,
>
>The problem stems from the *internal* validation of date fields done by FPD/FPW, particularly the date of Feb. 29, 2000.
>
>In addition, the default century is 19 for those versions. This of course, can be addressed by careful coding and using 4 digit year entry areas or some "window" processing to accomplish a correct default.
>
>Even the problem of Feb. 29, 2000 *can* be addressed - there was an article in last month's FoxPro Advisor magazine which had the details (I'm not sure if it was all there or if you also need to diskette available with the publication to get the whole solution).
>
>VFP 5.x offers "correct" handling of these things and a built-in "ROLLOVER" feature to allow you to automatically treat dates as 19xx if the number is before a certain value, else as 20xx (when entered as 2-digit dates). HOWEVER, there appears to be one deficiency with that "solution", namely that it seems to issue an internal SET CENTURY ON as soon as a date calling for 20xx is entered.
>
>Hope this helps,
>Jim N
>
>>Hi all,
>>
>>current implementation of Year 2000 project in my company has raised a
>>question of FoxPro 2.6 (DOS and Windows) being compliant with Y2K. Now,
>>I know that both FPD and FPW 2.6 physically save dates in YYYY/MM/DD
>>format in DBF table, and the way you (or your user) are going to see it
>>depends on SET CENTURY and SET DATE settings. If I'm not mistaken, same
>>thing is with VFP 3 and 5, as well. For same reason, the prevailing
>>opinion here is that FPD and FPW 2.6 are not compatible with Year 2000
>>standard, but having in mind the facts above, I really wonder why would
>>that be. Can somebody please shed some light on this issue? TIA,
>>
>>Srdjan