Table Corrupted 2

[ROGERIORIOS]

I was changing the structure of a table in the database and forgot it was open in a query.

There was an error in the VFP , it crashed and closed.

Afterwards I received the message that "field did not match".

I removed the table from the database, renamed it and got it from my backup.

I didn't include it in the database, I just tried to open it and VFP says the "dataini" field doesn't exist.

I'm not understanding the reason for this message as if the VFP was treating the copy of the table as the corrupted table

 

[Chris Miller]

You remove the table from the database. With REMOVE TABLE?

Then just restoring a backup of the DBF (and related CDX or FPT, if there are) will not add it back to the database. The DBC still has no information about the DBF and all long field names are lost, because you modified the DBC and told it to forget anything it knows about the table.

To fix that, I suggest you restore both the table and the DBC/DCT,DCX to pull everything together again including the long field names.

Chriss

 

[Mike Lewis]

Restoring the table from a backup isn't enough. If you have made any changes at all to the structure of the table or the database itself, you will probably need to restore the entire database, that is, the DBC and all the DBFs (and all the indexes, etc.)

But keep in mind that you will then lose all the updates you did since making the backup.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ROGERIORIOS]

What did I do :
1- I removed the table from the database with the command REMOVE TABLE tbturma
2- I made a Validate Database
3- I downloaded 2 files: tbturma.dbf and tbturma.cdx
4- I renamed the corrupted files.
5- I copied the copies that I downloaded from the host into the folder where the tables and the database are.
6- When I try to include the VFP it says that the table already belongs to the dbcadsatro database (which is the database it actually belongs to)

So since I can't include it in my database I try to open it and it gives an error (in the backup file)
USE "\\secretaria-pc\cvt\geral\tbturma.dbf" excl

 

[ROGERIORIOS]

Ok,First I'll try to create an empty table and import the records.

 

[ROGERIORIOS]

When I turn it into a free table I can't use it because of a field that has more than 8 characters

 

[Mike Lewis]

You seem to be digging a deep hole for yourself. I think you have little choice but to restore the whole database (as per my and Chris's posts, above).

In addition, you might find this article useful: Fixing broken backlinks in DBC and DBF files.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Good advice from Mike.

I didn't make it clear enough, but you have to know the DBC contains information about fields of DBFs belonging to it. As I guessed you used REMOVE TABLE. Well, that removes informaiton about the long field names and the DBF itsefl does onl have short field names in its header. But it's header also has a backlink to a DBC, as it belongs to a DBC. So when you restored the DBF it knows it belongs to a DBC, but since you used REMOVE TABLE and also VALIDATE DATABASE afterwards, that DBC doesn't know the DBF and things don't match.

So restore DBC/DCT/DCX files of the database and restore the DBF/FPT/CDX of the table, and a) the DBC will know the DBF and its field names, and b) the DBF knows its DBC and the DBC knows the DBF and everything will be fine.

In very short: Just doing what I said would have already solved that situation, restore both the table and the three dbc files that store all the database information about itself and its tables. I don't know what's hindering you to try. If you fear that you lose other things you changed in the DBC, then make copies of these files before restoring.

Chriss

 

[ROGERIORIOS]

Thank you for your help.
1-I created another identical and empty table in the database.
2-I downloaded the backup of the table in another folder.
3-I exported this backup table to a third table.
4-Then I opened the empty table in the database and imported the records.
5-Then I recreated the indexes.

 

[Chris Miller]

Why? All you had to do was restore the one table and the DBC files.

But you can also solve it the hard way.

Chriss

 

[Chris Miller]

I think ROGERIORIOS already moved on. Fine.

So, to any future user trying this out: Don't.

At first stage, with a corrupted DBF, it's sufficient to only recover the DBF backup (that means table.dbf and related files like table.fpt, table.cdx and maybe more .idx or .cdx files).

ROGERIORIOS must have thought along the lines it's best to remove the corrupt table, then restore a healthy old version of it and add it to the DBC. That doesn't work, because your backup table already belongs to the DBC. You can only add tables that are free to a DBC and the backup copy isn't a free table. What's worse is, that once you already removed the corrupt table from the DBC, restoring the healthy DBF you can neither add it to the DBC nor can you remove it with the commands ADD TABLE or REMOVE TABLE. As Mike said it, ROGERIORIOS has dug himself into a hole.

The option you are given in the message ROGERIORIOS posted that offers to free the table, you lose all properties of the DBF that are part of the DBC, that's not only concerning long field names, but also features like default values. Then adding it with ADD TABLE is possible, but you don't get back to the old structure with all long field names and other DBC based features the table had.

You have contradicting information in DBC and DBF in that situation and there is only one easy way out: Restore the DBC to the state it was before you did REMOVE TABLE, by simply restoring it together with the DBF backup and everything is in sync again. The backup also doesn't know about your last structural change, so that has to be repeated, but so what? You can get back to the healthy state and this time make your table change while the table is not "open in a query", as ROGERIORIOS said was starting the problem.

Sidenote: Something did change that caused the corruption, an ALTER TABLE or editing the table structure in the table designer would have failed completely and couldn't have caused any change at all, if the table wouldn't be able to open exclusively so that a table is "open in a query" actually means nothing. If it could be altered in any way, it wasn't open "in a query". It's a thing that you can't really say about a table anyway. A table can be queried and the query result can actually be a filter of the DBF itself, which you can detect by checking DBF('queryresultalias'). If it's not the DBF, it is a TMP file and that can still be open, while the DBF can be closed. And so you can alter a table that was used in a previous query, that's not a hindering reason nor is it a reason that corrupts a DBF when you alter it as a query result is not the DBF itself. In case the query result is a filter, you wouldn't even get into the table designer or your ALTER TABLE command would simply fail and do nothing.

So it's not even clear what caused the corruption here, but once corruption is given, the simplest thing to do is restore the table. There only was a corruption in the table, not the datbase. So in the first place just restoring the table will be sufficient, if you don't have changed anything in the DBC itself. If you already fiddled with things like REMOVE TABLE or VALIDATE DATABASE, then restore the table.DBF, and other table.* files and also restore the files of the database container, the database.DBC, database.DCT, database.DCX files, and also everything is in sync between the DBC and the DBF and all other DBFs of the DBC.

In very short: Just make use of the backup in the first place. You can always as very first step set aside the corrupt table plus the DBC files into a separate new folder for the purpose of trying to restore some data from it. But only try getting at lost records as aftermath, don't begin your journey with the path that you don't know will lead to a recovered healthy state, begin your journey with recovering the table in the last backup state and then continue to improve from there, that's always simpler.

Just as an exercise without any corrupted table, you can copy just these the DBC/DCT/DCX files of your database container and files of just one table into a new folder with the same relative location of files. This means, if your tables are in subdirectories also create the subdirectory. Now OPEN DATABASE and USE the copied table. This will work, though all other tables are missing from the copy. The opening of a DBC does not check for the existence of all tables and other meta information it has about them. So you can always set aside just one table of a database together with the database container files and in case the DBF is corrupt try to fix it or get at the last records in it that were not in the backup. Then there are table repair tools out there, even though many vendors of VFP software are gone out of business. Doing it this way means you're taking out the time pressure to get back to a recovered state. The loss of some records should simply not be your first concern at all, the first concern is to get back to a recovered database the application can use again that enables users to work again, especially in a company where waiting for this causes costs much higher than the loss of records of a day.

I know, in a shop that can mean the orders of the last day and then it is important to get back the data about that, but you have more time to get at them and as many tries as you like, if you always copy your copy of the corrupt data before trying a rapair.

Chriss