>>>I'm getting ready to rewrite the re-indexing routine of a large VFP 3.0 application. The old routine does not delete the .CDX files. It uses ALTER TABLE to drop the a table's primary key, then creates the primary key and other indexes (including foreign keys), then creates the table's triggers. After doing this for all tables, it (re)creates the database's RI.
>>>
>>>I remember an earlier posting (Barbara P.?) about deleting the .CDX files first, but didn't save the message and can't find it in my searches(I'm a basic member). Seems it was better than rebuilding the file.
>>>
>>>Does anyone have comments/suggestions?
>>
>>VFPs REINDEX uses the data in the cdx header to reindex. This can cause index 'bloat', because indexes that are no longer used are still contained in the .cdx. Also, if a cdx is corrupted in the first place, the new index can be corrupted as well. Deleting the .cdx first causes VFP to create the indexes from scratch. There is no automatic way of doing this for all tables, because when you delete the .cdx, you have also erased which indexes were there in the first place, and you must either manually or programmatically recreate each one. BTW- Stonefield's Database Toolkit has a method that does this automatically, and can because Stonefields Data Dictionary stores the index information in its meta-data. Pretty handy tool, if you ask me, and has nearly been worth the price of the toolkit. HTH
>>
>>Erik
>
>Thanks, Erik. This is as I thought. I'll ERASE the table.CDX, then create the indexes and triggers. It's the RI rules that most concern me. I will take a look at Stonefields Data Dictionary, but we haven't even been able to get management to spring for 3.0b!!
>
>Dallen

Just an idea...you may want to look at the GENDBC code for a less expensive alternative.

I made my own version of GENDBC which is modified from the original and restores tables AND BACKUP DATA which is created when GENDBC(x) is run. The RI are stored in a .krt file.

HTH

Matt