Y2k: Cinderella: XBASE Problems Revisited - Topic 015 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 Clipper and 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 '66'). The compilers such as Clipper and 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 Clipper or 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 Clipper 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 Clipper, Quicksilver or Pcfdb 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 '2024.02.02'. Other functions such as CTOD etc, also work correctly. Chris Anderson 2023-09-17 ------------------------------------------------------------------------ Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za http://www.cinderella.co.za Striving for Year 2000 Compliance ------------------------------------------------------------------------