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

The above problem occurs only when the year of date is entered as 2 digits.
Am I right?

Does the earlier versions of Foxpro store only 8 digits?
Does the 8 digit include 2 slashes(/) also?
So 02/11/1997 is having 10 digits
and 02/11/97 is having 8 digits . Am i right ?

I do not find any problem if the 'century is on' while accepting dates from user or system. If any possible problems or any confusion in my understanding of the above problem, Please enlighten me .
-- Satya
>>
>>>
>>>  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. :-)
>
>Well Paul, that's nifty. I like that. But you missed the logic a bit.
>
>This is what it would be using your calculation
>

>lnCent=INT(year(date())/100)
>lnRoll=MOD(year(date()),100)-30  && start the window 30 years prior to today
>
>*- correct for century since prior century entries are still possible
>IF lnRoll < 0
>   lnCent = lnCent-1
>   lnRoll = lnRoll + 100
>ENDIF
>

>Thanks Paul.