There is more info available on this new behavior at http://support.microsoft.com/?id=814131. The suggested fix for the problem in that article uses ALTER TABLE rather than PACK, as it doesn't depend on the presence of, or remove, deleted records.

You can turn off the checking (and emulate behavior of past versions) with SET TABLEVALIDATE, but I wouldn't recommend that.

The fact that a particular 3rd party product doesn't detect or fix the condition should be brought to the attention of the developer of the 3rd party product.

>Hi,
>
>I am not talking here about the situation when entire records are hidden because they were not accounted in the header. If I recall it correctly, versions before VFP6 were sensitive to this corruption. And it is good that MS returned back here.
>But if it is just a piece of one record, then it leads to confusion, it cannot be fixed by existing third party products, and reasonably (I believe)was ignored in the previous versions (including at least DOS 2.5).
>
>>Hi,
>> The actual error is caused by the table header file size info not equalling the actual table size.
>> This is a great enhancement, as previously, when it occurred it caused the transaction tracking to fail, and all subsequent appends to the file failed.
>> If you wish to see an irrate high speed data entry operator, then use VFP7, especially when they have just realized that the last 5,000 records they have input have disappeared into the bit bucket.
>> A simple error prior to the loss of the first record is much more acceptable.