Have a look at SET TABLEVALIDATE.

VFP6 (and maybe earlier) and VFP7 tolerate the case of a table's header record count being incorrect (this is what the "corruption" is) whereas VFP8 goes back to the old way and does not. Typically the header count is less than the actual count of records in the table, rendering the 'extra' records inaccessible.
VFP8, however, adds the SET TABLEVALIDATE feature so that you can get behaviour similar to VFP6/VFP7 BUT I THINK THAT ANYONE WHO WOULD IS CRAZY.

*IF* the table does have deleted records then in VFP8 you can PACK the table after setting TABLEVALIDATE TO 0 and that should "fix" the "corruption" but of course the 'extra' records will be lost (they are already effectively lost because they are inaccessible anyway.

The critical thing too with VFP8 is that, when running 'normally' (SET TABLEVALIDATE TO 3) VFP8 will (at least it's designed to) error when a record is about to be lost, thus making the fact of lost record(s) known to you (your VFP7 table lost a record or records yet you didn't know!).


>We a table which VFP 8.0 can't open it because it's corrupted but actually it runs well in 7.0. I already detached the table in the DBC, packed it, reindexed it but nothing happens. Anyone encountering this kind of strange behaviour.