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?

>The KB article in question reports a VERY SERIOUS problem.
>
>The article notes that it is applicable to VFP 5.0, VFP 5.0a and VFP 6.0 and was last reviewed 1/22/2002. I note that the review date is significantly after the release of VFP7.
>
>This article was also mentioned in a discussion of a locking problem in VFP 8 and it was noted there that VFP 8 has added an OPEN of tables to verify the accuracy of the header record count.
>
>So the question is: what is the actual status of this serious bug as relates to VFP 7.0 and VFP 8.0?
>
>Thanks