I was going to add something, then thought better of it (a not-so-practical idea, it was).

Sorry



>Hi 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.
>>
>
>I was pleased to hear that this problem has been addressed in VFP8. But on second thoughts, I am concerned that this may not adequately handle the situation.
>
>It is fine to highlight the problem and throw an error, if a table has become corrupted, and a user attempts to open that table.
>
>However, consider a multi user situation where three users are (amongst other things) concurrently posting to a transaction journal. They all start by successfully opening the table. But it the table becomes corrupted in the course of a posting from one of the users, then I see the current problem recurring, with data being lost. The error condition needs to be detected when the data is being appended to the table. It would certainly not be acceptable to lose data, and wait until later when some (other?) user attempts to open the corrupted table. That was my point in the threads on the issue.
>
>Geoff