00018: Rebuilding corrupted MKEYED files

Title:

Rebuilding corrupted MKEYED files

Description:

It is better to try to replace the damaged header with the header of a recent backup. Since you don’t know precisely where the chains start, there is no way you can restore the pointer information to the header of the file through the Norton Utilities. 

If a recent backup is available, you usually save more time (and money) by simply restoring that and then having the operators key in any lost transactions. With small files this time-savings is remote, but if the file is a major one that is used by many programs within the application, think of all the down-time for the users while you try to save them a few hours’ work rekeying transactions. It’s usually just worth it from a typical business’ point of view. 

However, if you look in the BBx/TAOS Applications Library here on CompuServe (Library 6), you should find several programs you can try to use to rebuild the MKEYED files. BASIS does not guarantee those files will work; they were written and contributed by customers who have run into this problem before (usually where no backups were available). 

An alternative method, if circumstances force you to attempt recovery of the data in the file, is to define a new MKEYED file and then copy the records out of the damaged file to the new one. This technique requires that you know what the records look like, as the records and keys are interspersed in their blocks throughout the file, and that your data not contain binary numbers in the first four bytes of the records, as that is where the delete pointers are placed by BBx. 

The data in an MKEYED file usually starts at the second 512-byte block in the file, but some headers are 1024 bytes long. You should be able to determine with the Norton Disk Editor where your first data block begins. Then, you need merely scan through the file to determine at which 512-byte block the first key block exists. This will tell you how many 512-byte blocks are allocated for data in a group. 

Next, count the number of contiguous key blocks until you get to the next data record block. This will tell you how many key blocks to skip when you read through the file. 

Once you know this information, provided you know what the data records look like, you can read through the file and extract the records. You should have a reliable data model to test the record contents; often people don’t, so you may have to do this blind, in which case I can’t guarantee you this method will work. 38MB is too much data for an interactive recovery where you look at and approve each record before it’s written to the new file (IMHO). 

Anyway, as you pull the recovered records out of the old file, be sure to test the first four bytes to make sure they aren’t deleted records. 

In most business application files, key blocks are easy to identify because the keys are usually considerably smaller than the data records. The blocks also contain a lot of binary numbers between the keys (and at the beginning of the blocks). 

If you don’t like any of what I’m saying, you can get some idea of how the header of an MKEYED file is structured from the program “_fixmkey”, which should be included in your utility set. This is an undocumented program and BASIS put a strong warning into it. 

Whatever you do, make sure you have a good backup of what’s left of the file before you do anything irrevocable. 

Last Modified: 02/10/2004 Product: PRO/5 Operating System: All platforms

BASIS structures five components of their technology into the BBx Generations.