>>>>Has the DBF file exceeded 2GB size? This could make repairs a wee bit trickier.
>>>
>>>This was a FP 2.6 and below issue. VFP doesn't let table exceed 2GB.
>>I've seen situations in VFP applications where a table "crashed" because it went over the 2GB size limit -- the INSERT or APPEND command would indeed add a record and the record count would update -- but soon afterwards you'd get a runtime error. Indeed, as you say, VFP won't allow the table to exceed 2GB -- you get an error that point (unfortunately you still have a table that now cannot be opened). Fixing it requires that you either decrement the record count (and lose the last record added), or use an external program to effect the repair. The low-level file functions in VFP will work for the first type of solution, but not for recovery of any data past the 2GB size, as the low-level file functions in VFP appear to be subject to the same 2GB limitation.
>
>Like I said, that's not my problem. The table is way smaller.

If the table is less than 2GB in size, then it should be possible to use the low-level file functions to edit the header -- basically you need to decrease the record count indicated in the header so that it fits the file size. Basically the file size should be no greater than the header size plus the space for the records (which would be the record size times the number of records). The typical error you get is when the record count would mean that the DBF file would need to be larger than the current physical size. The other "fix" would be to use the low-level file functions to append blocks of data to "pad out" the file so that it could physically hold the number of records as indicated in the DBF header.. In the typical case, the record count indicated in the header is too high by 1 -- so decrementing it by one, or padding out the DBF file by number of bytes contained in one record, would be enough to effect enough of a "repair" for you to open the DBF file normally.