Hi Mike,

>Additionally, we do additional file size checking in VFP 8.0 that we didn't do before, hence the reason the file can be opened in 7.0 but not in 8.0. The table is still more than likely corrupt (though maybe not, since there was a since-fixed bug that reported corrupt tables when they weren't), 7.0 just didn't complain about it. The formula is as follows:
>
>FileSize - SizeOfHeader = SizeOfRecord * NumberOfRecords
>
>If that's not the case, VFP throws an error. Fixing this can be a little more tricky than the "off by one" header corruption, since you don't necessarily know how the file size got corrupted, nor what to trim or add to fix it.

That's great, but if the check remains only at the table open stage, itmeans that if corruption occurs, it will only be detected by the next user to open it, and even that may not be known to someone else doing batch entry. Unless VFP8 has since been changed, the data loss continues to go unreported, and I cannot fully trust the integrity of new data entered.

Geoff