The Holmes Page: CA-Clipper Tips & Tricks - Data File Headers and the Year 2000

Home

Web Design

Programming

Fairlight CMI

Soap Box

Downloads

Links

Biography

About...

Site Map

Data File Headers and the Year 2000

CA-Clipper

Opportunities

Tips and Tricks

Networking

Internal Errors

Source Code

CA-VO

BACK TO
CA-CLIPPER
TIPS & TRICKS

Although the DBF file format is supposed to be a standard, different database applications have different ways of handling the last update value in the file header.
Phil Barnett has a page

at the Oasis that lists various database products and their handling of the year 2000+ in the header of DBF files. Because the behaviour of CA-Clipper is altered depending on the RDD used, I have combined information from his page with my own findings for the SIx RDD and the Advantage Database Server.

Data File Headers and the Year 2000

Product or RDD	Year 2000 is represented as	Can open with 00 in header	Can open with 64 in header
CA-Clipper (most RDDs)	00	yes	yes
CA-Clipper with SIx RDD	00	yes	yes
CA-Clipper with COMIX 3.0 RDD	00	yes	yes
Advantage Database Server v4.4 or below	64	yes	NO!
Advantage Database Server v4.4a or above	64	yes	yes
dBaseIII+	00	yes	NO!
dBase IV 1.5	64	yes	yes
dBase IV 2.0	64	yes	yes
Visual dBase 5.5	64	yes	yes
Fox 2.6	00	yes	yes
XBase++	64	yes	yes
dBXL 1.3	64	yes	NO!
Arago (dBXL) Lan 2.5	64	yes	yes
CA-dBFast 2.0D-2	64	yes	yes
Quicksilver	64	yes	yes
MS Excel from Office 97	64	yes	yes
MS Access 2.0	64	yes	yes

Based on data from http://www.the-oasis.net/clipy2k.htm

Thoseproducts or RDDs that can open a file with 64 in the header but use 00 to represent the year 2000 will store 00 if changes are made.
Check out Thomas Leylan's A Clipper Y2K LUPDATE Patch

for a method to fix the the lupdate() function.
Visit my Handling Dates page to find out more about date fields.

Advantage Server Y2K Bug in 4.4 and Previous Versions

Thetable reflects my recent encounter with an error in the Advantage Database Server (ADS). Extended Systems, the manufacturer of ADS, claimed Year 2000 compliance, but one of my clients had to undergo his own corporate audit, where the error was revealed.
The following is not intended to scare you away from the Advantage Database Server, but to show you that Y2K errors are sometimes not where you expect them to be and can effect the best of us. Advantage Database Server is an excellent product, offering incredible performance and providing a viable alternative to common SQL engines. I am an Advantage reseller, so contact me for the best price around.
The ADS Year 2000 problem occurs in versions 4.4 and earlier of the server software and involves application error 7016 (Corrupt .dbf). The ADS manual explains: "The specified .dbf file contains corrupted data in the file or field headers."
My client's application automatically switches between the ADS RDD if the server is available on the network and the SuccessWare SIx RDD when stand-alone. The error did not occur with the SIx RDD. Extended Systems obtained the RDD specifications from SuccessWare when they began development of the Advantage RDD, so we had expected the behaviour to be similar.
Every table in my client's system contains some special character fields, which are composed of the full range of ASCII values from 0 to 255. These fields are essential in order to synchronize record updates between the travelling laptops and the master data files on the network server. The fields store the date, the time, the identity of the user, plus checksums to detect tampering.
We initially thought that the problem was related to "binary" characters in these fields, because the fields are indexed. We even said as much in a message to Extended Systems technical support:

The error only seems to occur when the table is first opened by Advantage and only if the first record contains "illegal" characters. From this we assume that ADS performs a simple integrity check on the first record when opening a file. If the file is kept open by one workstation and another stores illegal data to the table, ADS does not present an error. Only when the file is finally closed by ADS (as a result of the last user logging off) and re-opened (the next morning for example) does the error appear. In other words, as long as the table is kept open by at least one user, anything can be written to the fields and the system works properly.
These fields are also indexed, and ADS perhaps does not allow binary characters in indexed fields. The indexing routines in ADS are presumably written in C, which uses chr(0) to terminate strings. Thus, ADS might include a simple check for illegal characters to ensure that indexing works. This is all just conjecture, of course.

Anyway, all of that turned out to be a wild goose chase! We were taking guesses based on the symptoms that we saw. In fact, any value can be stored in character fields, and be indexed properly.
We told Extended support about two "identical" files, one opened with SIx on the laptop, and the other with ADS on the network:

The only difference between the two files (using DOS FC):
  Comparing files
  CH_SIX.DBF("good" file) and CH_ADS.DBF("bad" file)
  00000001: 00 64
Note that all editing was done with the workstation and server date/time in the year 2000.

This byte (the second byte of the header) is the century portion of the date returned by the lupdate() function. The SIx version "wrapped" around to 00, which is the general behaviour of Clipper. However, the ADS version incremented the century to 64 hex or 100 decimal (which is better than 00 anyway).
With this important bit of evidence, Extended Systems support responded:

Your comment about the year 2000 clued me into what is happening. We've got a minor bug in our server code. [emphasis added] It's reporting a dbf as corrupt, when it's not actually corrupt. There was some confusion as to whether a header setting indicating the last date of update was a string or binary value. This is definitely to be fixed in the next release. For now, be assured that the database is still completely valid. It's a logic error in our checking the file's integrity.

Ah ha! So the Advantage Database Server incremented the date value in the header (properly) when changes were made after the date/time crossed over into the year 2000. As long as the table was kept open, everything was fine. But when the table was closed and then re-opened the server code checked the century value in the header and emitted an error, because the validation code was broken.
They sent us a "temporary fix" 4.4 server, which corrected the problem. Extended Systems subsequently officially released it as version 4.4a. My client did not need to upgrade to version 5 (which includes the fix) to satisfy his corporate Y2K auditors, although version 5 has features of its own worth considering!
All of this happened back at the beginning of November 1997. My client caused a stir on the CompuServe forum at the end of March 1998 when he asked about the availability of the official patch (as he was still using the "temporary fix"). Nobody seemed to be aware that there was a problem with ADS except my client and I!
Extended Systems made the 4.4a server software freely available to all 4.x customers. Since the problem was only at the server end, applications do not need to be updated to newer client interfaces, although there may be other reasons for doing so!
Visit my Handling Dates page to find out more about date fields.