>Hmmm... Warren said that a REINDEX brings the indexes back in synch.
>
>Now a REINDEX effectively does an internal DELETE TAG ALL and then rebuilds indexes based on the TAG info saved before deleting it.
>Since the index **IS** repaired by the REINDEX, why in the world would the other way provide any better result????
>
>To me there is far too much FUD spead here about REINDEX. I'd bet that 99.9% of the time REINDEX works just fine.

Nowadays, yes. The idea of killing off the indexes and building them from scratch came to me naturally some eight or more years ago, when I was seeing indexes messed up beyond recognition. Not only the indexes were bad sometime, but their headers also, so the table couldn't be opened at all.

Haven't seen more than a couple of bad indexes in the last four years, and then it happened because of a loose network cable. So for most of the cases, Reindex will do just fine. It's just the matter of do we want to code for that one-in-ten-thousand case; chances are that in such a case more than just the index may be messed up, and having a good backup would help more than just having an unbeatable indexing routine.