Jim

>We made a change in VFP8 to address the issue described in http://support.microsoft.com/support/kb/articles/q293/6/38.asp. Records added in a transaction can be lost when the table is corrupt in such a way that the header record count disagrees with the actual number of records in the table.
>
>Now we check at USE whether the header record count and actual number of records in the table agree, and give the error if the table is corrupted, i.e. the two don't match.
>

Further to my inital reply, I have done some testing using the Beta.

I used a modified version of the method described in Q26902 to corrupt/repair a table, located in a directory on a server.
With the table header valid, I opened the table from the VFP8 dev machine, and opened the browse. On a second machine, running VFP7, I then opened the table, and ran the utility to corrupt the table.
Back on the VFP8 machine, I put the browse into append mode, and 'added' a record It did not in fact save the record, and did not produce an error.
closed the table, and tried to use it again. Got the new error message,
which is quite informative, and points to the action required.

So from VFP7, fix the header, and browse the table. The 'appended' record was not appended, (also evident from the VFP8 browse).

While the error checking at the 'use' is a good idea, the downside is the repair method can't be run from VFP8. But the real problem is not fixed - data gets lost, at least up to the point where somebody else opens the table
and that is not acceptable in any serious application.

Geoff