Larry --

As far as Y2K is concerned, SET CENTURY ON by itself does not do much for you, other than display the date with a 4-digit year. Try this:

1. Create a 2.6 table with two date fields in it (Date1 and Date2), then APPEND BLANK to give you a record to work with. Then do the following:

SET CENTURY ON
REPLACE Date1 WITH CTOD('01/01/99') && Or use DATE() if you wish.
REPLACE Date2 WITN CTOD('01/01/00') && Hoping for 2000???

2. Now BROWSE your table. You will see that Date1 has a 4-digit year of 1999, and Date2 has 1900 (were you expecting 2000?).

3. Now enter a date with a 4-digit year like this:

REPLACE Date2 WITH CTOD('01/01/2000')

4. BROWSE your table again. This time Date2 has the correct year in it -- 2000.

This illustrates the fact that SET CENTURY ON does not completely solve the Y2K issue in FoxPro 2.6. Your alternatives are to a) force your users to enter a 4-digit year (as simulated in step 3 above); or b) create a piece of code (i.e. a VALID snippet) that forces in a century 19 or 20 as appropriate.

The nice thing about X-Base tables (All versions of Fox, dBASE, Clipper, etc.) and the newer RDBMS's (SQL Server, Oracle, etc.) is that all date fields ars stored with a 4-digit year. That leaves the interface for us to deal with. but even so, we are way ahead of those poor COBOL guys out there who have to fix all of the pre-Jurassic files that have 2-digit years in the date fields.

Bill


>I just tried the following in Fox2.6 for Windows and Fox2.6A for DOS and it saved the date properly.
>
>SET CENTURY ON
>REPLACE dDate WITH Date()
>
>>Thanks again for your help Bill. I would like to ask your help again on the same topic, however, I am going to restate the problem.
>>>
>>>Currently, the application has places within the prgs. in which a field in a database table is replaced with the date() function.
>>>
>>> e.g. Replace dDate With Date()
>>>
>>>The data type for the field in the table is Date. I forwarded my PC time to 01/01/2000 and tested the app.. Anytime time that the above situation occurred, the date in the table field was 01/01/1900. In addition, I have also placed Set Century On in the main.prg.
>>>
>>>Any ideas as to how to handle this?
>>>
>>Jason --
>>
>>It seems that the SET CENTURY ON/OFF command just controls the manner in which a table's date fields are displayed -- it has no effect on data entry. For example, execute the following commands:
>>
>> SELECT MyTable && Any table with date fields.
>> SET CENTURY OFF
>> BROWSE
>>
>>Your date fields will be shown with 2-digit years, although the full 4-digit years are actually stored in the table. Now do this:
>>
>> SET CENTURY ON
>> BROWSE
>>
>>The full 4-digit years are now shown in the browse window.
>>
>>As far as I know, the only way to handle the data entry problem you describe in FoxPro 2.6 is to force your users to enter the full 4-digit year when they enter a date. Of course, you could always write some code (probably in the VALID snippet for your date box) that would automagically plug in the century digits based on a cut-off year. For example, any keyed-in year in the range 00-70 would be changed to 2000-2070, while all other years would become 19xx.
>>
>>The SET CENTURY command in VFP has a ROLLOVER clause that takes care of this problem...too bad that it does not work for FoxPro 2.6.
>>
>>Again, I hope this helps you out, Jason. And by the way -- If any of you code warriors out there have a better solution for FoxPro 2.6, both Jason and I would like to learn about it from you!!!
>>
>>Bill