Just a thought, Geoff. . .

Might the table that was "recovered" be the only one with a Memo field(s) or possibly even be alone in having a field NAME of greater than 10 characters?

good luck,
jim

>Hi Jim,
>
>We were mainly checking the reliability of detecting the failure at the point where the transaction could be reverted and no long term harm done, (other than the need to repair the table, of course).
>
>The fact that one table 'recovered' of its own accord was the interesting bit, and I can't think of any way it is fundamentally different in its structure, or the way it's corruption was contrived. Will do some more checking on the 'lost' record, though, to be sure that the indexes are not affected if it 'recovers'.
>
>I am taking the view that once we have detected this error, it is time to have users run the repair.
>
>Geoff
>
>>>A further comment on this corruption, for anyone interested.
>>>
>>>I found an effective way to detect this problem is to commit an appended record with only the essential key fields, and then read it back and update it.
>>>
>>>To test it, I used a variation of the method suggested in another KB, to corrupt the header by reducing the correct header count by 1.
>>>
>>>It tested out correctly in three out of four fairly critical tables, updated in half a dozen or so places. In the fourth case, the header was corrected by VFP, after failing as it should have on the first attempt.
>>>
>>>Not entirely correct, though. In the update which corrected the header, the last record ( which I 'discarded' ) was overwritten. In practice, this might not matter, because the corruption to the header would not be as 'clean' as in the test case.
>>>
>>>It does, I think, suggest that the failure to report the error may well be related to VFP deciding that it has 'fixed' the problem, when in fact it hasn't.
>>>
>>>Geoff
>>
>>I wonder about this last bit. I wouldn't bet that VFP has consciously "corrected" the problem. It may really be more of a case that, in physically writing the record, the header gets updated too.
>>
>>Also, are you confident about the state of the indexes with this technique? For instance, if you do a SEEK on one of the values that you knowingly discarded, do you get an error of any kind?
>>
>>Things to think about anyway
>>
>>Jim