DBF TABLE IS NOT A TABLE ERROR

[Fernando Pereira]

Hi,

I have a table that when opening gives the error: "File is not a table".

I tried to recover with dbf recovery ... And I removed the tablevalidate, but without success ..

Any suggestion?

Thanks,
Fernando Pereira

 

[bborissov]

Try this:
CM TABLE REPAIR UTILITY

Borislav Borissov
VFP9 SP2, SQL Server

 

[Mike Lewis]

I used to have a whole folder full of DBF repair tools. But I just had a quick look at them, and the majority seem to be dead. The only one I can suggest, apart from CompuMotor which Borislav mentioned, is:

http://www.dbf-recover.com/

This is not a recommendation. I have never used it myself. But it would be worth a closer look.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Make a copy and open that in a simple hex editor... make sure there is something to recover!

Which version of VFP are you using? VFP 6 is more tolerant than VFP 9
Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

Last time I came across 'file is not a table' the file had been encrypted by ransomware

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Just to follow up Griff's two posts ...

If you open the DBF in a hex editor, you need to look past the first big chunk of data, which will contain a lot of binary zeroes amongst other stuff (the size of this block in bytes will be a little more than 32 multiplied by the number of fields in the table).

After that chunk, you should recognise the actual data in the table: names, addresses, invoice numbers - whatever is applicable. If you can see that, you have a chance of recovering the data. If you can't, let's hope you have an uo-to-date backup.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Fernando Pereira]

Hi,

First of all thanks for the suggestions, which have already given to investigate and try some options.

With Cm Table Repair I was able to open the table.
But all the lines are blank.

Any idea what it might be?

Best Regards,
Fernando Pereira

 

[Mike Lewis]

Did you try opening the table in a hex editor, as per the above suggestions? If so, could you see any recognisable data, such as names, addresses, etc? If not, then I am afraid that - to use a quaint English expression - you are stuffed.

If you don't have a hex editor, I would recommend HxD Hex Editor, by Maël Hörz. Other hex editors are also available.

Next question: Do you have an up-to-date backup?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Fernando Pereira]

Hi,

I opened the file with a hex editor, and the only thing I see are dots ("...").

No, the customer does not have any backup.

Thanks for the suggestions, anyway.
I managed to reconstruct the information until the month of August 2020, so that only partial information from September is lost.

The customer will have to redo it manually.

What has no solution is resolved.

Best Regars,
Fenando Pereira

 

[Mike Lewis]

Fenando, good to hear that the problem is solved - apart from the missing data after August.

But there are a couple of points you still need to attend to. First, if at all possible you should try to find the reason that the file became damaged. It has happened once, so it can happen again.

The other point is that this is a very strong argument for frequent backups.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Fernando Pereira]

Hi,

Yes, you are right.
The point here is that the client is from a partner of ours, and although we always say to make regular backups.
We do not have full control over all customers, especially those who are not directly monitored by us.

In any case, the entity responsible for the client must already learn about the importance of backups.

Fernando Pereira

 

[Steve Meyerson]

My clients lose data, then call me. I don't even ask them any more whether they have a backup because I already know what the answer will be. Then they will say 'I know I should have and I will.' But of course I know they probnably won't. It's frustrating. What are ya going to do?

 

[Dan Olsson]

I can tell you what I've done

If it's after 17.00 (or 5 PM as they say in 3rd world countries), when the last user logs out, the system zips all relevant tables (without CDXs) and ftp them to our HQ.
Why not CDXs you ask? Saves some time and size. Also, I can always recreate them if they are missing or incorrect.