>>Anyway, I must hasten to say that the article was helpful, in confirming that
>>there was in fact a problem. There still is, and a suggestion or two as to
>>how to deal with it night save a lot of heartache for others if the article
>>was updated.
>
>Currently, the only suggestion I have is to check the file size/record count with code similar to that found in the article.

Hi Garrett,

I have to wonder whether MS really understands the implications of this problem.
Should this corruption arise, from whatever cause, an app continues to run, but no records are added to the affected table, and there are no reported errors.

At the end of a month, a user runs a report based on the affected table, and realises there is a problem. On investigation, only the records of the first week are there. The data has been lost. Now I know that index corruption can occur occasionally, without reporting an error, but reindexing will fix the problem, because the data is intact. Users are now encouraged to run a database utility on a daily basis, but even that can mean that several hundred records are lost. Not an acceptable situation for any of my users.

My workaround, at least until the underlying problem has been resolved, is to append the blank record, generate and insert the primary key, and tableupdate() to commit the record. I then issue a seek on the primary key. If that fails, I report the error and abandon the transaction. If it succeeds, I can proceed.

I used similar code to yours from the earlier KB to force/fix header corruption on several tables, in order to test this solution.

The place for the code to check the integrity of the table surely needs to be in the data engine. And in doing this checking, it needs to detect that the length of the file does reflect an integral number of records, as I have seen short records at the end of a corrupted table.

As I see it, we are looking at a problem which results from a BUG, which needs to be dealt with.

Regards

Geoff