Contents of the DIAGNOSE.TXT file
Diagnosing Data Damage
Discovering damaged data in your dBASE III PLUS database file can
ruin an otherwise pleasant day. Knowing how to assess the damage
is the first step toward recovery.
Diagnosing what is wrong with your dBASE database file and
recovering data from it can be a troubling process. In this
article, we are going to go over the procedures for assessing the
damage to your database. Then, we'll suggest ways to go about
recovering the data. Even if you don't have a damaged dBASE file,
you may find it useful to know how dBASE files are structured and
how to recover data.
We include discussions of two useful utilities: Xlate and
Fixhead. Xlate is a character translator that transforms a file
by replacing or removing every character in accordance with a
translation table. It can be used as a quick way of replacing
aberrant characters in the data area of a damaged dBASE file with
characters that will permit dBASE to regain access to data. (See
"Filtering Data" on page 25 of this issue.) Fixhead, as its name
suggests, is a program that allows you to repair damaged dBASE
headers. (See "Fixing a Damaged File Header" on page 21 of this
issue.) These utilities are provided on this month's Softstrips
on pages 67-71 and are also available from Ashton-Tate's own
Bulletin Board Service. See On-Line Services this month for
information on downloading software. We'll also discuss using
commercial file-recovery utilities when your data has been
seriously damaged. There are also many file recovery utilities on
the market, and some are specifically designed for use with dBASE
files, including Volume 1 of the dBASE Programmer's Utilities
How do I recover my data?
Recovering data from dBASE files does not have to be difficult.
You can ease the process, and your anxiety as well, by taking a
methodical approach. Take comfort in the fact that there is help
Preparation and planning, however, are as important as the actual
recovery process. If you aren't careful, you might destroy
otherwise recoverable data before you can recover it. This
preliminary phase of data recovery has five steps:
1. STOP what you're doing.
2. Use CHKDSK to resolve possible problems with the file-system.
3. Back up your files.
4. Investigate the damage.
5. Make a recovery plan.
As soon as you know something is wrong, STOP
Don't add any more records. In fact, don't do anything that will
change the disk that holds the damaged database. It's important
to note that your data could be anywhere on the disk. There may
be copies of records in areas of the disk that are not attached
to any file. There are data-recovery utilities that can recover
these records if necessary; but, if you create new files or add
to existing files, that data might be lost forever.
When a database is corrupted, there is a good chance that the DOS
file system is damaged too. Your first action should be to check
the file system on the diskette holding your database.
To do this, exit from dBASE and run the CHKDSK utility found on
your DOS diskette.
If you have a dual-floppy disk system, place your DOS disk in
drive A and the diskette with your database in drive B and type:
A:CHKDSK B: /F
If you have a hard disk, CHKDSK may already be on the hard disk,
in a directory such as C:\DOS or C:\UTIL. Assuming your hard disk
is drive C, and the damaged database is also on the hard disk,
change to the directory with CHKDSK and type:
CHKDSK C: /F
If CHKDSK is not on your hard drive, put your DOS diskette in
drive A and type:
A:CHKDSK C: /F
CHKDSK is a utility that examines the file system, provides
important statistics, and looks for several file-system problems.
CHKDSK can find
o lost clusters: portions of the disk that DOS has allocated, but
which are not assigned to an existing file
o bad sectors: portions of the disk that have a bad or unreliable
o allocation size errors: nonexistent disk sectors that have been
assigned to files
o cross-linked files: two or more files that appear to share the
same data area on the disk
Any of these problems can damage your database files, or they may
be the result of dBASE operating on a damaged database.
In any event, they can hinder the process of recovery; so, it is
important to take care of them before you proceed.
When you specify the /F parameter, CHKDSK repairs the damage, if
possible. If any problems are found, CHKDSK prompts:
Errors Found. Correct? Y/N
Type Y, and press Return to have CHKDSK repair the file system.
CHKDSK repairs the problems it finds in different ways. If lost
clusters are found, those areas of the disk are written to the
root directory in files named FILExxxx.CHK, where "xxxx" is
replaced with a sequential number beginning with 0000. You may
want to use a file recovery utility to search these files for
good data records before you finish your recovery.
Bad sectors are a normal occurrence on hard disks. Part of the
responsibility of the disk-formatting program is to locate and
mark bad sectors so that DOS will not try to store data on them.
If new bad sectors are discovered, you need to back up all the
data on the disk, reformat the disk, and then restore the
backed-up files. Reformatting a hard disk is not a process to be
undertaken lightly. You will probably want to attempt recovery
before reformatting the hard disk.
CHKDSK repairs allocation size errors by changing the size of the
file to exclude invalid sectors.
CHKDSK cannot repair cross-linked files. It will report the names
of cross-linked files, and you must handle them yourself. To
recover from this error, copy all the files named to a different
disk. Normally, you would then erase the cross-linked files and
restore the copy you made. Since you're about to attempt file
recovery, though, you should save the copies until you've
finished your recovery and then erase the originals and restore
Once you've run CHKDSK and resolved whatever problems it
encounters, load dBASE and attempt to access the database file.
Sometimes, running CHKDSK is all it takes to repair database
corruption, but this is rarely the case.
Back up your damaged files
Next, back up the files on the disk holding the damaged database.
If the database is on a diskette, use the DOS DISKCOPY program to
duplicate the diskette to a fresh one. You should use DISKCOPY
instead of the COPY command because DISKCOPY makes an exact image
of the diskette. The COPY command, on the other hand, doesn't
copy disk sectors that are not attached to a file. Those
unattached disk sectors, however, might be holding data records.
Put the original diskette in a safe place, and use the new copy
If you have a hard disk, back up at least the directory that
holds your database if not the entire hard disk. Use the DOS
BACKUP command, or your preferred backup utility program. Do not
simply copy files to another place on the hard disk, since this
could cause you to lose good data.
Do not, under any circumstances, back up your files over an
existing backup. You might later determine that it would be
easier to bring that backup up-to-date than to proceed with file
recovery. This is a decision you will have to make as you proceed
with your investigation.
Investigate the damage
Now it's time to investigate the damage. To begin, use the DOS
DIR command to determine what the current size of the database
is, and also to see whether there is another recent copy of the
file on the disk. Change to the directory with the database and
(substituting the name of your own database). DOS will provide a
report something like this:
Volume in drive C is MYDISK
Directory of C:\DBASE\DATA
MYFILE BAK 3876 05-19-87 3:22p
MYFILE DBF 4241 05-20-87 11:13a
2 File(s) 2691072 bytes free
In this case, we found a backup (.BAK extension) of the file that
was made the day before. dBASE makes a backup automatically
whenever you change the structure of the file using MODIFY
STRUCTURE or CREATE/MODIFY SCREEN. If a recent backup is out
there, your time might be better spent bringing it up-to-date.
If no backup file is available or the backup is too old to be
useful, then you should proceed to the next step, which is to
look at the number of bytes in the file. In this case, Myfile.DBF
has 4,241 bytes. You need to do some calculating to determine
whether the file size is appropriate for the number of records
that should be in the database.
If you're able to access the file with dBASE at all, use the
LIST STRUCTURE TO PRINT
to print out a copy of the structure. The printout will show you
how many fields are in the database, with a total record length
at the bottom. The total includes one byte that dBASE adds to
each record to keep track of records marked for deletion. If the
database is inaccessible, you need to reconstruct this
information using whatever resources are available to you. If you
have a backup, print out its structure. Otherwise, you will need
to jog your memory to recreate the file structure. For the task
at hand, you don't need to get the structure exactyou just need
a good estimate so that you can make an educated guess as to how
many records are in the database.
The number of bytes in the database header can be calculated if
you know how many fields there are. The header requires 33 bytes
plus 32 additional bytes for each field. (If the file was created
by dBASE IIIr, the header takes one additional byte.) Myfile.DBF
has six fields. Therefore, the header for this file should take
33 + (32 * 6) bytes
or 225 bytes. The remainder of the file is the data area followed
by an end-of-file marker. Subtracting the header size and the
end-of-file marker from the file size, Myfile.DBF has 4,015 bytes
in the data area. We happen to know that each record in
Myfile.DBF takes 55 characters, so the database appears to have
4,015/55 or 73 records.
Use your calculations to determine if the file appears to be
about the right size. Don't expect to be right-on-the-mark since,
after all, the database is damaged.
If the file size is reasonably close to what you would expect,
you can probably recover all or most of the records directly from
the file. If the file is much smaller, as it will be if you're
attempting to recover from an accidentally ZAPped database, you
will have to use a utility that can search the surface of the
disk for recoverable data.
Make a recovery plan
Already, you've collected a lot of information. The next step is
to begin formulating a recovery plan. If you've determined that
the file is a reasonable size, chances are good that you can
effectively recover the file relatively quickly. However, if the
file is too small to hold your data, your job is much larger.
In any case, before proceeding with file recovery you should make
a final decision about your backup situation. How many hours
would it take to bring the backup up-to-date? Is the information
you need to reenter readily available?
Weigh these factors against the prognosis for recovery. If you
have no backup or if your latest backup is too out-of-date, then
proceed with recovery. If, however, you have a relatively recent
backup and you have the time and resources needed to bring it
up-to-date, then restore it and get to work. You will need to
clean up the database by deleting duplicate records, removing old
records and, perhaps the most difficult chore of all, determining
what records should be there that are not.
It bears repeating that regular backups offer the quickest and
least painful form of file recovery!