Check out the Stonefield Database ToolKit - I'm a big fan of Doug's contributions in this area
HTH

>I'm trying to write a general purpose indexing routine generator, about
>the same way I wrote these things ever since 1989, and I'm stuck with a
>problem.
>
>The strategy was always to create indexes from scratch. Damaged index
>can't be open anyway, and a damaged structural index may prevent opening
>the table itself. So I had a routine to null the "has cdx" byte in the
>table header, then deleted the .cdx file, and then opened the table
>exclusively and indexed. In FPx2.x it worked like a charm.
>
>Now, in VFP, the primary key gets in the way. If I erase the "has cdx"
>byte and delete the .cdx, I can't even open the table, because it breaks
>with error=1576 (I think) and issues an ugly alert box stating I'd
>better Validate Database. The only way to circumvent this behavior,
>AFAIK, is to do things in this order:
> erase the .cdx
> open the table low-level
> delete the HasCdx mark
> nullify the dbc info from the table header
> close the table (LL)
> set up all the indexes
> open the table (LL), restore the .dbc info, close
> alter table ... add primary key ...
>This involves two low-level writes to the table, and probably the last
>"alter table" is due to cause another error, since VFP is probably bound
>to check the existing primary key. I can't just Alter Table ... Drop
>Primary, because this indexing routine is designed to work even if the
>..cdx is damaged or missing; Drop Primary also needs to have a proper key
>and a sound .cdx, otherwise it also requests Validate Database.
>
>In the days of 2.x I didn't care if anything happened to the .cdxes,
>because indexing created new and shining ones every time; now with
>dbc/primary key combination it doesn't seem to work anymore. The whole
>thing seems to be far less stable than it was. I've outlined couple of
>possible catastrophe scenarios:
>
>- bad .cdx, can't open table (missing primary key, Validate Database)
>- bad .dbc, can't open anything
>- table restored from backup or brought from another machine, won't open
>if its .dbc is absent
>- table restored from an older backup, when it had some other key -
>won't open.
>
>The worst is that some of the Vali Data options work from command window
>only; in an .exe there's none. Not to mention that I don't want any
>english text to appear before my user's eyes. Most of them know less
>than 20 words of the language and can't even read them properly, and why
>should they? It's my job to supply proper messages in their language(s).
>So, any solution to this... doommare which involves system messageboxes
>is unusable.
>
>Hints, anyone?