Y2k: Cinderella: XBASE Problems Revisited - Topic 015
(ERRATA: The initial post of this topic included
Clipper as one the "problem" dBase handlers. Thanks
to Patrick O'Beirne for pointing out that this is not
so.)
Ron Abbott has reported an interesting xBase Y2k
related bug.
When updates are performed with a system date past
2000, various dBASE compilers such as Quicksilver
modify the database header in such a way that dBase
iii3+ and dBase iv get a "Not a dBASE file" error and
abort. The original dBASE iii still works.
What is the problem?
Essentially this has a historical cause. When the
original dBASE iii was defined, the second byte of the
file, the "year modified" field, a single character
binary, accepted values greater than 100. So 2000 was
specifically allowed and defined as "100" (hex '64').
The compilers such as Quicksilver and other utilities
such as Pcfdb were defined on this standard.
Ashton-Tate then produced dBASE III+. This allowed a
new option called 'SET CENTURY ON' which would allow
displays of 4 digit years. Byte Two, "year modified"
was redefined NOT to allow values greater than 100, and
if this rule is broken the program aborts with error
"Not a dbase file". Similarly with dBASE iv.
What are the Y2k Implications?
The problem only occurs when the system date is in 2000
or beyond. Provided the SET CENTURY ON is taken, then
within a single product set the interface is consistent
and "acceptable". However when going "back" to the
Ashton-Tate dbase set from Quicksilver then the "not a
dBASE file" problem occurs.
So only "mixed" environments are affected.
Now this is a glitch, but it is not a terminal glitch.
I am not going to throw away a 30MB database because
one byte is miscoded.
All one has to do to fix the "broken" database is to
subtract 100 from the "year modified" and all is well.
The DOS directory date still reflects the correct
"date modified".
How to fix the Problem?
You can manually patch the database file using Norton
Disk Editor (DE) or some similar program. A freeware
program called Y2KDBFIX is available via anonymous FTP
from Cinderella at:
ftp://ftp.cinderella.co.za/pub (South African Site)
or ftp://parsifal.membrane.com/pub (USA Mirror Site)
What is the impact of "zapping" the Year Modified
field?
At this point the only place that I can find it used is
in "DISPLAY/MODIFY STRUCTURE". So in that context it
is cosmetic. Transactional changes to the database
would happen only in the context of a single database
handler, so that would not be a problem.
I am not aware of any usage (e.g. shared LAN support)
that would allow a database to be opened simultaneously
to a Quicksilver application and a dBASE application.
But such a "mixed" environment would not work
correctly.
What is the impact on other dBase functions?
Assuming a boot date of 2000-02-02, the hex dump of a
database created on that date would be '03 02 02 02'.
If updated using dBASE iii+ or dBASE iv then this would
be unchanged. If updated using Quicksilver or Pcfdb or
dBASE III the header becomes '03 66 02 02' and aborts
under dBASE iii+ or dBASE iv with 'Not a DBASE file'.
Zapping byte two to '02' (i.e. subtracting 100) fixes
the problem.
If 'SET CENTURY ON' and 'SET DATE ANSI' are used then
the DATE() function correctly returns '2000.02.02'.
Other functions such as CTOD etc, also work correctly.
Chris Anderson 1997-09-17
updated 1997-10-25