>Hi Jim.
>
>>I don't think it makes much difference at all, really, for any of the following:
>>1) REINDEX command;
>>2) REINDEX with a 'blanked' index;
>>3) A series of INDEX ON commands to 'rebuild' the index from scratch.
>>
>>However, #1 is obviously far more convenient,especially as concerns database-resident tables that may have PKs and relationships defined. Also less error-prone, at least from a human-errors point of view.
>>#2 or #3 could cause problems *if* one had somewhere along the way forgotten to amend the 'blanked' CDX or the command sequence to match some action taken on the live table.
>>
>>#1 got a bad rep, probably deserved at some time long ago, about running incorrectly if the .CDX 'header' record(s) were 'corrupted' or for 'bloating' the CDX or for propagating 'corruption' from run-to-run. But the fact today is that #1 works fine except if there *is* 'corruption', at which time #2 or #3 are the only ways around things. But that shouldn't deter anyone from exploiting the convenience of #1. A corrupted CDX likely still has a good chance of REINDEXing perfectly correctly because it takes corruption in a very specific place for it to do otherwise.
>
>One other issue with #1: I have occasionally seen CDX files that were so badly corrupted that VFP GPFs on the USE statement. In that case, you need #2 or #3.
>

Yes, that's what I tried to say with "...except if there *is* 'corruption', at which time #2 or #3 are the only ways around things.".

I get the general sense that there is more CDX corruption happening now than, say, 1 or 2 years ago. My guess is that faster processors and/or less skilled users/app setups (turn off w/o shutdown, more peer-to-peer, etc) and/or deficiencies in VFP or WIN (possibly related to faster CPUs and unskilled users) are at the root of the problem.
I'm especially wary of Win's cacheing mechanism which, from anything I've read on the subjct, quite clearly is designed for things like Word documents or Excel spreadsheets or SQL Server and decidedly not for random record multi-table (and file) updates/writes.

Any comments?

>Doug