I have run across several cases where a system lost power or crashed in
the middle of a FoxPro session after which FoxPro reported the file
corrupt. Yet upon scanning the file with a file editor, it is mostly
intact. Are there any repair capabilities built into FoxPro of which I
may be unaware?
-- Kevin
A favorite of the Fox gurus is dSalvage. For more info visit this site:
http://www.accutek.com/comtech
This web page contains product information as well as discussions about some
of the more common file damage problems.
> I have run across several cases where a system lost power or crashed in
> the middle of a FoxPro session after which FoxPro reported the file
> corrupt. Yet upon scanning the file with a file editor, it is mostly
> intact. Are there any repair capabilities built into FoxPro of which I
> may be unaware?
Here's more info on the "Not a database file" error message:
I have experienced the "Not a Database File" error many times. This problem
is really not that serious if you know how to handle it. It is seldom seen
in a single user environment and is much more common in a peer-to-peer
non-dedicated server situation than on a Novell network with a dedicated
server.
On a Novell network with a dedicated server this problem will *frequently*
occur if the server goes down, in power outage, for example. For this reason
an uninterruptable power supply (UPS) is recommended for the server if power
interruptions are a problem in your area.
Usually, though not always:
1) The DBF file actual, physical record count does not match the record
count in the DBF file header.
2) The DBF header record count contains one more record than is actually
(physically) present.
3) If you decrement the record count in the DBF header by one the DBF
file pops right back.
WARNING: THE FOLLOWING PROCEDURE CAN DESTROY YOUR .DBF FILE.
ALWAYS MAKE A BACKUP!
Bring up the DBF file in your favorite hex editor (Norton, PCTools, etc.).
Bytes 4-7 contain the record count. Since the hex editor starts counting at
byte 0, it will be the 5th byte in from the left. Decrement it by one, e.g.
if its 05 change it to 04, 0B change it to 0A, etc. Write it out to disk. Go
into FoxPro. Try to USE it. If you still get "Not a Database File," repeat
the procedure, decrementing byte 4 by one again.
The count is stored in the header backwards, or reverse order bytewise, so if
you have to decrement byte 4 past 00, then byte 5 must be changed also. For
example:
Bytes 4-7 # records in DBF
----------- ----------------
FF 00 00 00 255
00 01 00 00 256
FF FF 00 00 65535
00 00 01 00 65536
So in row two of the above table (00 01 00 00 = 256 records) if you wanted to
decrement the record count in the DBF by one (to 255 records) you would have
to change both byte number 4 (to FF) and byte number 5 (to 00). (FF 00 00 00
= 255). This same principle pertains across all four bytes.
This procedure looks hard, but its really simple. It doesn't work all the
time, but a lot of the time it does.
Also, there is an article in the November 1993 FoxPro Advisor magazine
entitled "So It's Not A Database File," on page 20 that will tell you
everything you need to know about how to handle this situation, and then
some. It was written by Fox gurus Jim Booth and Paul Heiser. Paul is the
developer of the aforementioned dSalvage file recovery utility.
Hope this helps...
--
Bob Ruple
http://www.ix.netcom.com/~bruple