Thunderstone Support Forums

When attempting to index one of our tables we received the following errors:
005 Corrupt next header at 0x1675af30f in KDBF file \\192.168.1.11\openshare\PTOData\PATN.tbl in the function read_rest_data

and also

005 Bad size 1035529899 for column GOVT_PAx at offset 0x91E in recid 0xD0B4C3D7 of \\192.168.1.11\openshare\PTOData\PATN.tbl in the function fbuftofld
100 Error in data, file \\192.168.1.11\openshare\PTOData\PATN.tbl, offset 0xD0B4C3D7

I ran kdbfchk (without the repair option) and it returned the following:

Bad block summary:
27 orphaned free blocks found
67 free block pads inserted
* Corruption detected *

I do have back ups, but assuming that running kdbfchk with the repair option works to fix the file, is there a way to determine which *record(s)* in the table is/are corrupted in the event I need to replace that data?

Thanks.

Were there any other errors just before or after these?

kdbfchk would not be able to detect or repair the `Bad size' error, as it is at a higher level (table logic) than KDBF.

You could copy the table via SQL (which would detect the `Bad size' and other errors), then see which row(s) are missing from the copy (i.e. the ones with errors), e.g. by comparing unique ids (if the table has such a column).

It is normally not advisable to put a table on a network-accessible drive, as that can lead to exactly these sort of corruption errors, because the Texis locking mechanism -- needed to manage concurrency and avoid corruption -- is single-host based and cannot know that other machine(s) may be manipulating the same table(s). Are you sure no other machine was manipulating the \\192.168.1.11\openshare database while you were creating the index?

Offline discussion noted that proper network-drive precautions were being taken: no mods to the table/database while the index was being created.

Also brought up another hypothesis -- that the corruption actually existed *before* the table was copied, but has only shown up now because this was the first index create since the copy. Thus this is the first SQL command to actually read 100% of the table -- i.e. including the corrupted row(s) -- since the corruption happened. Previous Metamorph index *updates* (not new index create), or partial SELECTs/queries etc., may only have read other (valid) rows in the table.

Kai... Again, thanks for your help on this. Turned out to be a BAD DRIVE!!! Grr!!!