>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