>>>>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

Why not:

lnCent=INT(year(date())/100)
lnRoll=MOD(year(date()),100)

IF lnRoll < 30  &&  correct for first 30 years in century
   lnCent = lnCent-1
   lnRoll = 100 - lnRoll
ENDIF

IMHO, it's a little more clear.

>
>  SET CENTURY TO (lnCent) ROLLOVER (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. :-)