>WOW!
>That's quite a list of things to do!
>I had no idea. Is all of that really necessary? I just want to get rid of my indexes and create them from scratch. I never heard of "the zero bit on the 28th byte of the table header" let alone clearing it...
>And I never heard of "the binary memos in the dbc."
>
>And at this time, I wouldn't know what to do with them if I did.

You actually got me thinking how much work would it be to rework my gen_dex.prg to be generally usable. I'm using some of my framework code in it, but some of that is already here in downloads, and some can be replaced with the newer Fox commands (like the InputBox() replacement that I don't need anymore). May even catch some time and post it as a download here. Not sure it's perfect, but the code it generates is already in use in one commercial app, plus the dozens of FP2.6 apps generated with previous versions. Another hurdle with publishing this code would be the translation of all the comments, which start in 1989 :).

As to why is all that really necessary:

Clearing the zero bit of the 28th byte of the header: if you are rebuilding the index because it's screwed, chances are that the .cdx header is screwed, in which case you can't even open the table until you erase the cdx. But then it will complain about cdx missing, but with safety off you can open it in second try (don't ask how much time did it take to discover this). With the bit cleared and .cdx file erased, the table is completely indexless, and will open.

Clearing relations - you discovered that yourself.

Clearing code in the database - that's necessary if there's any code in it, because the code may mention some tags and other stuff that may or may not be absent during the process. The way out is to save the code, erase the code (via Append Procedures from a zero-length file), recreate all the indexes, append procedures back.

Clearing primary keys - at the point where you have erased all the indexes, it will error out if you try to open a tagless table for which the DBC still holds information about the primary key. The information is binary, but it can be extracted and later reinserted.

You also need to recreate all the indexes in their proper collating sequences.