Data File Headers and Year 2000

How does Halcyon handle the last update year in the DBF header for Year 2000? There is only a single byte to hold the year. Is it $00 or $64 for 2000?

The xBase "last updated" date stored in the .DBF header has a problem in some languages and implementations. The header of the .DBF file stores the last update in bytes 1, 2 and 3 in hex.

0 filetype checkbyte
1 year( date() ) - 1900
2 month( date() )
3 day( date() )

The problem is that some software which reads and writes to .DBF files handles the year byte differently. There appears to be two types of different handling.

1. The software continues to increment the year byte beyond 1999.
2. The software does not continue to increment, but wraps to 00 instead.

The problem is that some software considers the DBF file corrupt if the year format is not what it expects, which can cause problems if you move between software.

There is a very nice synopsis of this on Greg Holmes Data File Headers and the Year 2000 page.

Halcyon stores the year as year mod 100, which gives a rollover as in FoxPro. However, Halcyon does not really use or check this value, it just maintains it. In the LUpdate function in TgsDBFTable for the basic engine, it gets the file's actual file date, as recommended by Microsoft. In the THalcyonDataset component descended from TDataset there is not even a call to get this value, (via a function LUpdate) so you would have to get the file date.

Bottom line: Halcyon will open with either 00 or 64 in the year byte. It will store as 00. It will not fail regardless of the format it opens with.