DB3FIXPO - Version 1.0

by

P. L. Olympia, Ph.D.
President, Darwin Systems, Inc.
SUGI SIG/M RBBS, 301-963-5249
11/14/84


WHAT DB3FIXPO DOES

DB3FIXPO is a program that repairs or recovers a damaged dBASE
III data base in 15 seconds or less regardless of the size of the
data base. It was designed to save you lots of wasted hours, gray
hair and money. It was first used on a damaged file with 1 Meg
worth of data and did the job in 10 seconds. Even Ashton-Tate
does not know that the recovery can be made this way, or if they
do, they are not telling you. It can also do less demanding fixes
described later in this document.

I am hereby placing the program and this documentation in the
public domain. You are free to share the program and its doc file
with others on the following conditions:

1. DB3FIXPO.EXE and DB3FIXPO.DOC are distributed together, and
their names are not changed;

2. No changes are made to either DB3FIXPO.EXE or DB3FIXPO.DOC;

3. The files may NOT be sold. Give them away but don't ask any
money for them. I am giving them away to you so you do the
same.


DISCLAIMER

I will not be responsible for any damage this program may do to
your data. Now, that's a little funny since the program works on
DAMAGED data but I am obligated to say it nonetheless (I am not
crazy about this legal mumbo-jumbo either). The program has
always worked for me. If it does not work for you, chances are
it is not the program's fault.


A LITTLE BACKGROUND

I have always told my staff to backup their dBASE III data bases
at the end of each day. If you've ever done any serious work with
dBASE II and III (which I like very much, but are nonetheless as
bug-ridden as the Mekong Delta) you know that it is good advice.

Yesterday, dBASE III reared its ugly head. During a full screen
edit operation on a data base with 1 Meg worth of data, the color
screen went flashing and the system became terminally ill. The


DB3FIXPO (c) 1984 Darwin Systems Inc. Page 1








data base was thoroughly damaged (dBASE III can't even recognize
its own data base). The last backup was done 4 days before and
was seriously out-of-date. The staff member is still with us but
only because she has other attributes which we won't go into
here.

Because a complete report off the data base was needed the next
morning, I stayed up the whole night to recover the data base.
Here is what I did that night to recover the data:

1. Since the file was too large to repair via DEBUG, I wrote a
program to find the beginning of the data records (the
header record damage extended into the data area). Now, this
took a lot of tweaking because the header record did not end
where it was supposed to end).

2. Having found the beginning of the data area, I wrote a
little program to dump the data records into a text file,
and add a CR/LF sequence at the end of each record. The
program took 2.5 hours to complete its job. That is not the
program's fault - there were just too much data. In fact,
there were so much data that at the end of the run, I had
very little space left on my hard disk.

3. Next, I took a file containing the same structure as the
damaged data base and ZAP(ped) its data records. (If you are
unlucky enough not to keep a file with the same structure as
the damaged file, all you have to do is re-create the
structure via the dBASE III CREATE command). Then I
APPEND(ed) the dumped text file generated in step 2. and
Voila!, the damaged data base was completely restored!!

Although the procedure worked, it took nearly eight hours, used
up disk space like it was going out of style, and took a lot of
painful tweaking and some manual intervention. There had to be a
better way, so tonight I stayed up the whole night again and
wrote DB3FIXPO that did the same thing in 10 seconds, and did not
use a single byte of additional data disk space.


HOW TO USE THE PROGRAM

Before you use the program, you need to have two DBF files:

1. The damaged DBF file (of course), and

2. A DBF file containing the correct structure of the damaged
data base. You either generate this with the dBASE III
command COPY STRU TO or simply by recreating the structure
with the CREATE command. It is NOT necessary to have any
data records on this second DBF. The program simply uses it
to reconstruct the damaged data base's header record.

You also need to know approximately how many data records were in
the damaged data base. If you don't know this number take a guess


DB3FIXPO (c) 1984 Darwin Systems Inc. Page 2








and pick a number LARGER than what you think the correct number
is. You can always DELETE the garbage records at the end of the
recovered data base.

If your data base damage did not extend into the data area, then
all you have to do is run the program and answer "N" to the
prompt,

"Do you want to change the length of header record (Y/N)?"

The program assists you in determining the extent of the damage
by dumping the contents of the damaged file beginning with the
expected beginning of the data record area. If the data base
damage did not extend into the data area, the first or second
byte displayed should be the first CHARACTER of the first FIELD
in the data base. If this is the case, your data base is fully
recovered and you can now invoke dBASE III and USE your recovered
data base. If this is not the case, put on your thinking cap,
and read the APPENDIX below.

DB3FIXPO is as self-documenting as I can make it. Invoke it at
the DOS prompt and just follow the instructions and respond to
the prompts.

ADDITIONAL USES AND NOTES

DB3FIXPO can also be used for some relatively simple fixes:

1. Suppose you have a dBASE III DBF file with a MEMO field (I
don't much care for MEMO fields at its present state of
development). Now, suppose you somehow lost the
corresponding DBT file. Tough, dBASE III won't let you open
the data base so you can at least recover all the other data
except for the MEMO field data. DB3FIXPO can patch your
data base so that dBASE III will think that there is no MEMO
field or DBT file associated with the data base.

2. The program, obviously, can also be used to correct the
data record count should that ever become corrupted.

DID YOU KNOW?

1. That the dBASE III command

APPE FROM DELI

does not work correctly. Now, you know why the DELIMITED
option is not in the manual. One approach is to do the
APPEND FROM DELIMITED of a comma-delimited file
into dBASE II and use dCONVERT to turn that into dBASE III.

2. That (speaking of ...) dCONVERT is unable to turn a dBASE
III DBF file into a dBASE II file. That menu option number
7, for d(un)CONVERT is a cruel joke perpetrated on people
who don't know any better. I'll write that utility later.


DB3FIXPO (c) 1984 Darwin Systems Inc. Page 3









APPENDIX - ABOUT THE LENGTH OF HEADER RECORD

If the damage extended to the data area, pay attention to the
byte dump that the program shows on your screen. You are looking
for the BYTE number that corresponds to the first CHARACTER of
the first FIELD of your data base. This does NOT have to be the
character belonging to the first data base record (if the damage
extended to the first data base record, this record may be lost
and you are looking for the first character of the first field on
the second data base record). This sounds complicated but hey, I
had to figure this out from scratch!

Let us look at an example.

Suppose you have a data base whose structure begins with:
NAME,C,30
COMPANY,C,40
CITY,C,25
... other fields ...

Now suppose the first 2 records in the data base begin like so:

Jane Good Miles J. Away
ABC Corp XYZ, Inc
Rockville Zamboanga

If the damage is extensive or the length of header record is
wrong, your "recovered" data base may look like this:

NAME: :
COMPANY: Rock:
CITY:ville Mi:

The business of adjusting the length of header record is to have
the recovered data line up correctly. The first character of NAME
(the first field in the data base) should be either "J" (from
"Jane Good" of the first record) or "M" (from Miles J. Away of
the second record).

Suppose the byte dump of FIXDB3PO later shows you this:

BYTE CHAR
451
452
453 J <-- note this byte # (453) and subtract
454 a 1 from it. Re-run the program and
455 n use the result (452) as the length
of header record.

CONCLUSION

Implicit in all the foregoing is the fact that when your data
base is damaged, your data records are intact. Don't delete the file.
Do a backup on the damaged file and run DB3FIXPO on it. ENJOY!!!


DB3FIXPO (c) 1984 Darwin Systems Inc. Page 4