
butil -stat and corrupt files
On 28 Aug 1997 20:19:54 GMT, "matt tagliaferri"
Quote:
>We have a Platinum btrieve file that occaisioally becomes corrupt (status
>2). We perform a "butil -clone" and then a "butil -Copy" to "rebuild" the
>file and remove the corruption. Before and after this rebuild process, I
>run a "butil -stat" on the file to get a record count, so I can determine
>if any records are "lost" in the copy process.
>The last time I ran this process, it told me that the rebuilt file was
>approximately 50 records smaller than the original. A high-level VP wanted
>to know exactly what records were missing. After designing and running a
>process to determine this, I found that there were only 8 missing records
>in the new file, not the 50 that were reported.
>My question is this, if a file is known to be corrupt, is it possible that
>the "butil -stat" would return an invalid number of records? This would
>easily explain why I got a different number from my own process (one I am
>almost certain is accurate), and the "butil -stat"
>value.
If the original file is corrupt. how are you determining that only 8
and not 50 records are missing?. anyway, it is possible that the
header information 'pre' recovery is incorrect, especially if end of
record markers were blown out ( this would result in 54 errors on the
butil -load).. If you successfully recovered all the records into an
ascii file, it would be possible to determine exactly which records
are missing, but even then it would be suspect. If you are
consistently getting 2 status errors, you should investigate the
cause. A common cause is if clients are mixing different btrieve
clients(BTRIEVE & BREQUEST) and accessing the file at the same time.
A word of caution about BUTIL.. it is not the best method to recover
corrupt BTRIEVE files.. if an error is encountered while reading
forward through the file, BUTIL will then go to the end of the file
and read backwards until it reads the last record successfully read,
or until another error is encountered, at which point it stops..
remove leading '#' when replying via email