>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?


In FOX 2.6 (Dos and WIndows) I have a routine that rebuilts the cdxs based on information I store in system tables in case the cdx is damaged etc. This worked very well. When VFP came out it did not take long to realize that the same routines would not work anymore, either on tables or cdx files because of the info needed or stored in the DBC. This was going to be big job. That is why I bought Stonefield Database Toolkit. For $249 it was LOTS CHEAPER THAN MY TIME!!! After I saw all the code required to do that simple reindex job I realized: WAS I EVER SMART!

The very best advice I can give to anyone who ever thinks they might have a corrupted table or index with VFP: BUY STONEFIELD DATABASE TOOLKIT. It will be way cheaper than trying to do it yourself. If you don't like to use 3rd party products, remember, you get all the source code so you never have to get an update if you don't want to.

I was having problems recently with a table that was always having the index trashed (wasn't a VFP problem) and that caused the users all kinds of grief. The quick and simple solution was to put the code in the error routine of a button that [1] deleted the cdx file and then [2] call the Stonefield reindex method that recreate the index. A couple of lines of code and it works like a charm.

VFP is getting too complicated to write everything ourselves. Sometimes we need to invest a little in our environment (frameworks, etc)