Table only opens in VFP 6 3

[amrmnabil]

Hi all;
I have a table that only opens in VFP 6.0. If i try to open in in VFP 9.0 it returns a massage that the table is corrupt.

 

[Tore Bleken]

Then your table is really corrupt. VFP9 does a more thorough check before opening a table, so a table with a "hidden" error may be opened in earlier versions while VFP9 correctly reports that it is corrupted. But it will also help you fix it.

[pre]lcTable = 'yourcorrupettable.dbf'
lcTemp = 'temp' + sys(2015)
lnTableValidate = set("TableValidate")
set tablevalidate to 0
use (lcTable) exclusive
copy to (lcTemp)
zap
append from (lcTemp)
use
set tablevalidate to lnTableValidate[/pre]

Note that it's extremely important to leave the tablevalidate value at a high value except while you fix a corrupted table!

http://fox.wikis.com/wc.dll?Wiki~SetTablevalidate

 

[Mike Lewis]

If you still have a copy of VFP 6, then the obvious solution is to open the table in 6, then copy it to a new table. Copy the actual data to a new table; don't just copy the physical file.

One way to do that would be:

[tt]USE OldFile IN 0
COPY TO NewFile[/tt]

If the file is part of a database, add the [tt]DATABASE[/tt] clause to the [tt]COPY TO[/tt]. And don't forget to include path names if necessary.

Alternatively:

[tt]SELECT * FROM OldFile INTO TABLE NewFile[/tt]

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[amrmnabil]

tbleken and MikeLewis thanks for your reply.
I have VFP 6.0. I opened the table in 6 and copied the table to a new table and the new table worked well.

The strange thing that i tried to repair the table with DBF doctor it also could not open the table and said some thing about the data environment.

Any ideas about what caused this?

 

[Olaf Doschke]

I don't know dbf doctor, how aged is that tool? If it doesn't know VFP9 dbfs it can't repair them.
Besides both the solutions had/have a danger in them.

Being able to open a dbf in VFP6 still does not tell VFP6 to "understand" the table. If it contains new field types introduced in VFP7-9, VFP6 can't cope with them, also not copy them.
And copying to e temp.dbf, zapping the dbf and append back can not only crash at the wrong time, the copy to might cuase shortened names and data could not appended back fully.

The simplest reapir would just open the dbf in tablevalidate set to 0, append blank, delete - these two steps correct the reccount of the dbf header, then pack to get rid of the new empty record which could be harmful with any next append blank, if there are indexes enforcing a uniqueness of values, you can't append blank twice in such tables before the blank record has got its individual values and not removing the blank record with PACK could cause that later when the application needs to APPEND BLANK.

All that is only repairing the reccount header defect, if you had more serious defects you can't repair in such ways.

You lost a record, at least, a record not getting into the dbf has caused the reccount to get higher than the number of real records and VFP9 checks file whether file length is in conjunction with the header. But it's not the only possible defect, there are more serious.

Bye, Olaf.

 

[Tore Bleken]

Read the link I sent you, it describes why VFP6 does NOT report the problem.

 

[amrmnabil]

Thanks you all for your help