>>>Because of the Year 2000 transition , Foxpro will not face any problem. Am I right?
>>>If any possible problems that could come because of Year2000. Please do suggest me
>>>
>>>You can mail to me at 'spvedulla@hotmail.com'
>>
>>Intrinsically, no. FoxPro has been Y2K ready for a while now. Even better in 5.0 with the inception of the ROLLOVER.
>>
>>The only thing you really need to be careful of is you will have date entries that span more than 99 years (i.e. on record with 10/10/1965, another with 10/10/2070), hence the rollover won't work for you and you'll need 10 digit date fields instead of 8.
>
>
>Could you enlighten me more on this 99 mystery ?

On second thought, it should be 100, but to clarify:

I use the following function:


FUNC f_Y2Kfix
LOCAL lnCent, lnRoll

lnCent=VAL(LEFT(allt(str(year(date()))),2))
lnRoll=VAL(RIGHT(allt(str(year(date()))),2))-30

IF lnRoll



When run at the beginning of the app, I end up with a 100 year window, starting 30 years prior to today, which Foxpro will translate date entries with an 8 digit field. Hence for today:

07/31/70 = 07/31/1970

07/31/66 = 07/31/2066


I've TOLD VFP that I don't expect any date entries to be more than 30 years in the past or more than 70 years in the future. So it translates the entries accordingly and I can use 8 digit fields ok. But if my expected entry window were MORE than 100 years, THEN I would need to use 10 digit fields. I hope that makes sense.

I sure my apps won't be around in 50 years, but then, that's what all the COBOL programmer's thought in the 60s and 70s. :-)
-----------------
Does that mean It will change the system date?
Alas I didnot understand even now also, Could you Please explain elobarately ?