>>>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<0  &&  correct for first 30 years in century
    lnCent = lnCent-1
    lnRoll = lnRoll + 100
  ENDIF
  
  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. :-)