>The behavior described in the article happens in VFP7, but VFP8 traps for this corruption (where header record count does not match physical record count) at USE, and when data is written, i.e. BEGIN TRANSACTION and END TRANSACTION. SET TABLEVALIDATE controls the circumstances under which these errors are detected, the default is at both USE and when data is written.
>
>I sent through a note to have article 293638 updated with this information, and there is an upcoming KB article that will describe this and other data integrity improvements in VFP8.
>
>Just out of curiousity, have you ever run into this before?

PMFJI, but we have.
We lost a day's worth of data written inside transactions in our Belgian regional system.
Fortunately all data was also echoed to a transaction log database as well, for transmission to the corporate system in the UK. Since the logging was done in a separate database and a separate transaction (not nested) that wasn't lost.
So we were able to recover from that.

Next time it happened, both the custoemr database and the transaction log were affected and we had no backup at all.
Except that because we didn't trust our system at that point, we started writing all transactions to a text file with STRTOFILE(). Fortunately we could recover the transaction log from that and we lost no data then either.

Of course it took lots of time to find and fix the problems, but we didn't lose anything but man-days of developer effort.
It looks like LAN problems in the Belgian system, which are rather difficult to diagnose at this distance across a VPN tunneled through two ISPs :(