butil -stat and corrupt files 
Author Message
 butil -stat and corrupt files

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.



Mon, 14 Feb 2000 03:00:00 GMT
 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



Mon, 14 Feb 2000 03:00:00 GMT
 butil -stat and corrupt files

Quote:
>   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.

We are loading a backup "good" copy of this file from tape. The file is
unique in that records in it are never deleted through the application
(it's an inventory master file), so we can just look for all records in the
rebuilt file that don't exist in the backup, and we know exactly what
records were lost.


Tue, 15 Feb 2000 03:00:00 GMT
 butil -stat and corrupt files

On 29 Aug 1997 14:46:31 GMT, "matt tagliaferri"

Quote:

>>   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.

>We are loading a backup "good" copy of this file from tape. The file is
>unique in that records in it are never deleted through the application
>(it's an inventory master file), so we can just look for all records in the
>rebuilt file that don't exist in the backup, and we know exactly what
>records were lost.

 but what about records that were added in between the 'good' version
and the time the file went corrupt?? you recovered 8, but how do you
know there weren't 50 added between the backup and corruption?


Tue, 15 Feb 2000 03:00:00 GMT
 butil -stat and corrupt files

Quote:

> ...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?

I'm not sure I've met such a situation in practice, but
it will not be surprising if such things happened. Butil
reports number of records from the counter in the
header of a file, but this counter is updated on a fly,
e.g. during records add/delete operation. Obviously,
there exist moments when counter value on the disk
is not equal to the real record number. So if a file will
break down at this moment you will get what you've got.
(Not discussing preimaging, transactions etc.)

If you can write programs and your files break down
more then 2 times a year, I'd recommend you
to write your own recovering program. Developing of
such a program requires about 2 days of work but
with this you could (probably) say which records are
bad and you can implement various methods of browsing
and selecting good records.

Wish you success,
Vitalii

Moscow



Tue, 15 Feb 2000 03:00:00 GMT
 butil -stat and corrupt files

Basically, what the -stat operation is read the header page, which contains
the number of records in the file, along with other data, such as key
definitions.

If your file is corrupt, the number of records maintained in the header
page may be different to the actual number of records.

The is a very good utility to check and recover Btrieve files named
btrhelp. It can scan a file and look for records that are not found by
butil -recover.

By the way, I would recommend to do a -recover and a -load, because -save
and -copy both go by the keys, which can be damaged and could skip records
or even get into an endless loop in extreme cases. Also, you may go to your
platinum\data directory and pick the empty data file structure from there
or re-install the file from within platinum (there are only a handful of
files in there that are not empty)instead of doing a -clone. It will be
safer...

Good luck



Wed, 23 Feb 2000 03:00:00 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. Problem with - butil -stat xxx.btr

2. BUTIL description file format

3. BUTIL to determine file version

4. BUTIL / File Manager for NT 4.0?

5. estimating stats after computing stats

6. to compute stats or not to compute stats

7. Stats.log file

8. BCP Performance Stats to output file

9. Trace file format - parsing / getting stats on queries

10. Account.file.stats

11. MDC file stats entry interpretation?

12. capturing file stats for unidata conversion


 
Powered by phpBB® Forum Software