>I do have something against a broad statement that "REINDEX IS USELESS".

Yes, I can understand that POV is you use it.

>You serve to demonstrate exactly what BarbaraP demonstrates - that you do not use REINDEX (because you don't trust it). So how can you know if it works properly or not? You've been using a rebuild routine "since the debut", no doubt because of that age-old rumour that REINDEX can fail.

That command can only be bullet proof if no corruption is present on the tags. It can work, as you said, but we will never have any guarantee as depending on the level of corruption, it could affect the success of the operation.

>Do you really think that data gets corrupted that often? More importantly, how often of all those time that you do get corruption is it going to be in the first sector or two of the CDX?????? Believe me, NOT often at all.

Once a month, yes, that is often, especially for a product that has been there for 15 years or so. It was once per six month before, now, as I said and as many others have found with VFP 8, it's a little more. But, again, as mentioned, with VFP 8, the message may indicate it but it could be no corruption at all. So, it's a little bit confusing. For me, when I have a log in my error table which says something that the index was corrupted, I simply use the PRG to rebuild them all on the specific table. I basically don't have the time to go see if a corruption is present or not. Also, at four hits per second, on this site, if a corruption would really be present, when I have that log in my error table, it would mean, I would get a really big load of messages in a short time. Usually, when that happens, I only have one log which tells me that VFP got mixed up for some kind of reason. IAC, I simply run the PRG and rebuild them all. However, for the other situations, they did happen to me at several occasions in the past and I just prefer to be ready for something that will fix it when they happen and for something that will work all the time.

>There are alternatives to rebuilding indexes that are faster. Keeping and empty CDX, replacing the existing CDX with that, then doing REINDEX will be much faster than rebulding all indexes. Well, let me qualify that as never slower. But of course you have to "trust" REINDEX to do that.

Interesting, I didn't know of that one.

>I understand that .CDX's are subject to corruption. But also that the corruption happening in a place in the file that is hardly ever written to once created the first time is very very low.

Yes, it's the same thing that could happen with a memo field. It's very rare that the DBF gets corrupted but the related tables such as CDX and FPT, they could have a higher risk of getting corrupted.

>I take it that your routine does this on free tables. The job is a tad more difficult with DBC-based tables and using DELETE TAG ALL.

Yes, those are free tables.