Old trick - copy the contents of the file to coma delimited text file. Then, either zap the table (or preferred: copy structure extended and create from), delete the tags, append from the comma delimited file, and build the tags again. HIH!


>Jim,
>
>Actually this table is just a static one. It holds records for selection only but nevertheless it needs to be fixed otherwise we can't shift to 8.0 immediately. Thanks for your input and it helps me do something and it works. I opened the table in 7.0 and add a temporary field then it now opens in 8.0. I don't know yet if I'll SET VALIDATE TO 3 permanently the entire application. For now, maybe yes...
>
>>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.