Database, butil -stat and corrupt files

butil -stat and corrupt files

Author	Message
matt tagliaferr #1 / 6	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

#atede.. #2 / 6	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

matt tagliaferr #3 / 6	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

#atede.. #4 / 6	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

Vitaly Zagrebeln #5 / 6	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

Roberto Mancer #6 / 6	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

Page 1 of 1

[ 6 post ]