>My employer invested 2 years and $2,000,000 rewriting a number of large applications with a VB front end and a MS SQL back end. They just canceled the project for lack of results.
>
>This means I have ~6-8 months to Y2k the programs.
>
>They pass a lot of files between countries, mainframes and PCs on a massive network. One of the design parameters is that if you receive a date in mm/dd/yy format, you deal with it and return information in the same mm/dd/yy format.
>
>My problem is that if I read a text file and use the CTOD() function on 2000 leap year {02/29/00}, Foxpro 2.6 returns an empty date as 2/29/1900 is an invalid date.
>

I've had good success using Y2KFox, which handles this well. I'd still want to convert the app to a language that was fully Y2K compliant and didn't rely on a monitor like Y2KFox, but it's the cleanest interrim solution I've found so far that works. At this point, we've moved all but one app to VFP5 or VFP6 where there was any date sensitivity in house, but Y2KFox bought us some time, since we have systems that projected things a year or more in advance, and would've broken if it were not for Y2KFox.

The biggest drawback to relying on Y2KFox is that it's possible to start FPDOS/FPW without loading with Y2KFox accidentally. It the same problem as AV software - it's great that you own the latest and greatest, but if you don't load it up, it's not going to help a bit.

>
>My solution/question:
>
>Can I redefine the internal CTOD() function with a routine that performs the Y2k conversion on the text before the text to date conversion?
>
>If I can, how do you redefine internal commands (I can handle the specifics of the conversions).
>
>If I cannot redefine an internal command, do you have any suggestions other than brute force seek and destroy methods for replacing all instances of CTOD()?
>
>Thanks,
>Bryon