>>>Just a heads-up: at a client I ran into a situation where missing index tags caused extreme slowness.
>>>
>>>In my case a table (in a DBC) with just under a million rows has a CDX file which was supposed to have 8 tags: one on the primary key plus 7 others. Somehow, the 7 non-PK index tags were no longer present, only the PK tag remained.
>>>
>>>With the "bad" CDX a test report took 22 minutes to run.
>>>
>>>When replaced with a "good" one and reindexed, it took 5 seconds to run (250x faster).
>>>
>>>Over the years I've encountered a number of corrupted CDX scenarios. However they've always been such that the app won't start at all or crashes quickly with an obvious index problem. This is the first time I've run into tags that just silently went missing, without causing any functionality problems with the app (other than slowness).
>>
>>There was some sense in Rushmore :)
>>
>>That's strange.
>>
>>So I have some questions.
>>Is the CDX just with one tag? Then, how can a CDX be changed so that it is not corrupted (i.o.w working) other then by DELETE TAG? So to do the question the other way around what is causing DELETE TAG in you app?
>>Is the size of it something like the size of a new created CDX with just the PK?
>>
>>Does seek return meaningfull results. IOW depending on your design, is iot possible to copy - rename an other CDX? My approach would work, sort of at least. The PK seems to be related to record by coincidence (incrementing number - RECNO() )
>>But this might fail for records not in the wrong file. A run comparing seek with the result?
>>
>>Lutz
>>
>>Are the missing tags there but with other expressions? Since rushmore does not look at the tag but on the expression, what is changing the expression?
>
>The "bad" CDX had only 1 tag, on the PK as shown in DISPLAY STATUS with the file open. The CDX file sizes are consistent with that, the one with 8 tags is 32.8MB, the one with 1 tag 4.9MB.
>
>As I mentioned to Mike there has never been old CDX versions with only one tag. The table is in use pretty much 24/7 so it would be difficult to restore such a file even if it existed. No-one there runs VFP interactively so DELETE TAG couldn't happen, and exclusive access to do so would be pretty much impossible.

Hm, but a change like that need to result from something - so it's even more critical.

Subsequent backups to check? Something? There must have been some action, the question is how.

I guess you had a look inside the cdx with some HEX editor, just to check that there is only one expression / tag in it.
Create a cdx like the wrong one, bitcompare.

Pretty much is what 99.99%? This leaves 8.64s to replace - more then enough.

This all sounds cruel.
If you see nothing else, consider intention. Inside or outside of the company.

:(

Lutz