Restore DBF from CDX

[scrimej]

I have an application in VFP7. Users can't explain what happened. All I know is that a table with over 12000 records a year ago has 8 records today. All eight records were added today. I was able to find a deleted copy of the cdx file in the recycle bin and am almost positive based on deletion time that this is what caused the problem.

The index file of table missing records is about 8kb, the index file in the recycle bin is 348kb.

Does anyone know of a way to restore the contents of a DBF from the CDX. Not sure if this is possible going this way.

Thanks,
Jeremy

 

[bborissov]

No way,
Indexes contain only values of keys you used to build orders, not values of all fields.

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.

 

[Stella740pl]

Don't users have any backup at all?

 

[scrimej]

Yes, just trying to save them from losing 1/2 day of work.

 

[Stella740pl]

Yes, just trying to save them from losing 1/2 day of work.

You mean, between the time the backup was made and those 8 records?

It's not possible, unless you find other recoverable traces of that table. Of course, you can save them the 8 records into a separate table, and append them to the restored table.

 

[Scott24x7]

Mike,
You certain about that? I thought the index only kept on instance of the expression or compound expression, and the list of record numbers in the order which they appear... in no way actually keeping the data of any field.

Just ran a test against a table with 1,000,000 records in it, and 2 feilds. When I created the index with each field seperatly, the .CDX size was 10,868,224 while the table is 15,000,345. Using your logic, my CDX should technically be larger, holding both the expression result, and the order... so I think this is not correct.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

I think you're right. In theory, there could be cases where every item of data from the table could be reconstructed from the index, but that would be highly exceptional. You would have to have an index on every field, exactly as it appears in the table, without any sort of transformation on it (e.g. an index on forename rather than UPPER(forename)).

Admittedly, that doesn't explain why the CDX is so much smaller than the DBF in your test.

Anyway, even if Jeremy's table followed that highly exceptional case, it would be an extremely difficult operation to reconstruct the table from the index. Making regular backups is obviously a better approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Mike,
In 16 years of Fox, going all the way back to my 2.x days, I've never ever heard of this being possible... Even the old FoxDoc which could perform miracles on memo's and corrupt tables could not rebuild a table from an index...
Again, I believe this iss becuase fox stores the values of the record order themselves, in a interger "type" value within the "index" file, and not the actual result of the index expression that is created... I'm almost willing to bet money on that, and it does explain why my test creates an index smaller than the original table, even when creating un"expersionized" values for the fields. Compoud expressions create bigger indexes, I have proved that before with many index experiences with tables over the years...



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

I won't take you up on your bet. Even if I was right, it would only be in the very exceptional case I mentioned. I'm sure no-one has actually tried to do it.

You said you thought Fox stored the values as an "integer" type. I assume you are thinking of some sort of hashing scheme, where the characters in a string are reduced to a shorter number. Typically with those schemes, you can only go one way -- you can't reconstruct the original value from the hash (like trying to make eggs from an omelette).

You might be right about that. After all, the IDX index format (on which CDXs are based) is described as a "compact" index. However, if you open a CDX in Notepad, you can sometimes recognise the strings from the data.

You also say "compound indexes create bigger expressions". Compound indexes are in fact the same as compact indexes; the only difference is that you can have many of them in the same physical file. In fact, in all versions of FoxPro, all indexes are compact.

The term "compact index" was originally introduced to distinguish them from the old dBASE NDX format.

Interesting discussion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[scrimej]

Thanks for the feedback everyone, I quickly bailed on the idea of even trying to reconstruct the table from the index and went to the backup tape.

Jeremy

 

[lbfm]

Is it possible that the Index or cdx file may just be corrupt. I would delete the Index file, then recreate. Those other 12K records may appear. It would not take much to try this. A corrupt index could make it appear that there are no records, where once the index is removed, the records seem to appear again. A reconstruction of the indices would put you back to want to be, No promises on this one, but would not hurt to try it.