>>>May I get the solution for a corrupt dbf header i.e.
>>>"Not a table /dbf " error message in foxpro for windows
>>>
>>>I'll really appriciate if any one write to me thanks
>>
>>Hi, Try using FoxFix from XITECH corporation. It helps a lot to repair corrupted table.
>
>Sonny !
>I didn't get the file 'Foxfix' yet, will u please e-mail
>it to me at 'amehmood@ibm.net'
>Aamir from Pakistan

I know, I'm a day late and dollar short, but I've been having the same problem
on a multiuser system and have just solved my problem. Hopefully, this will work
for you, but I'm not sure as I'm not as accomplished as all the other people on this
thread and I'm sure I can't account for all the difficulties that may arise to render
a "Not a dbf/table" error. My problem was a result of a loss of network connection
due to a lockup on the server (Point to Point, shared data directory on server) which
occurred apparently during the addition of a record to the database. I have
many databases open but only 1 seems to have this situation occur and I'm certain it
is related to the APPEND as stated by someone else on the thread. Using the Foxpro
Developers Guide for 2.6 in the appendix under Table File Structure(.dbf), I played
around with my corrupt file using a hex editor on the record header. Of the things
I tried, what worked was changing the number of records (04-07) from the current
setting to the same setting minus 1 (e.g. 275 to 274). I saved the file and was able
to access it from within FPW2.6 and my memo field (.fpt) was intact. I would
recommend rebuilding the index's. I now have full access to my data again. It
appears that when the outage happens and an append in in process, incomplete data
is written to the record and since the record length is incorrect, the table is
determined to not be a dbf table. I tried the program available from the UT, but it
was for VFP5.0 and wouldn't work in 2.6. I'll now return to my reading as I have a
lot to learn as evidenced by the level of expertise on this thread. Hope this
helps you.