Sergey,
I have read and thought about the 2 knowledge base articles you referenced. It seems to me that VFP8 does not really fix the problem - it just gives you an alert mechanism. I am currently doing the equivalent to tablevalidate level 1, that is, checking reccount integrity after the table is opened. I have a valid table header before I do any data manipulation. The tables are opened buffered and blank records are appended. Data is then added and the records are posted inside a transaction. The tone of article 293638 would seem to indicate that the transaction itself is responsible for not updating the table header. (If it is the transaction, would I not be better off not using transaction processing?) How would one check for this? I guess my question is this, where does the corruption come in. Is it the append blank that does not properly update the header, or is it the transaction itself which does not properly assign the record # to the newly posted record and permanently update the recordcount in the table header. Or far worse, is it VFP not interacting properly with multiple users over the network.
I love VFP but this lack of data integrity is quite troubling.
A problem is a problem only as long as it has a possible solution. Lacking that, it becomes a FACT!