Is the program that successfully opened the table a VFP7 app? My bet is that it is, and VFP7 just goes ahead and opens tables regardless of an incorrect (some call it "corrupted") record count.

Have you looked at the SET TABLEVALIDATE feature of VFP8? It may give you a way to open it successfullyin VFP8.

Maybe the repair utility you tried can't handle a VFP8 table (because of auto-increment).

good luck

I'd still like to see a concerted effort on UT to IDENTIFY what is screwing up the record count in the first place, and I think yours is a candidate for helping in that effort.


>Just recently, after upgrading to vfp8, I have been having corrupted tables. I have been upgrading this app since vfp5 and have never had an issue with courrpt tables until vfp8.
>
>In some cases i am able to repair the table with cmrepair from the download section, but in most cases I have to restore from a backup.
>
>Today I noticed some very odd behaviour. I had a corrupted table. My forms crashed because it was in the DE. I could not open it with VFP8, because it told me it was corrupted. I tried the CMREPAIR utility and it reported the problem, but couldnt fix it.
>
>I have a routine that opens that table programatically, and it was able to open the table error free? and after that routine finished, the table was fixed?
>
>THe only difference I could note is the way the table was opened. It was opened via:
>

use '\\ecserver_pdc\public\data\ecnc\data\punchparams.dbf' in 0 shared

>
>THe table would not open through the VFP interface. What is going on?