>>You said that REINDEX was useless.
>>I **tried** to say that it was really only so when the CDX's first sector (or 2) of data had a problem and that that was rare. I **also** noted that sudden power offs or cable pulls can cause corruption BUT that the liklihood of the first 2 sectors of the CDX being clobbered was low to NIL.
>>
>>You came back with I still see corruption a lot.
>>Fine, but what makes you think that REINDEX would fail? How would you know if you don't use it?
>>Your statement was far too broad and I was trying to narrow it considerably.
>>
>>DougH said that he's never had a problem with PACK, nor has he heard of one, in 17+ years. Since PACK does use REINDEX I think that speaks for itself.
>
>At midnight, on our application, we have a robot program that takes all DBF from all directories and build the tag schema sequence. This has served me a lot so far when we had corruption. That has happened more since VFP 8. There is a new bug in there which fires the index problem but in reality all is ok. IAC, as we don't take any chance, we use that PRG for the tag schema and we recreate them all. By doing that, we don't have to worry about if the REINDEX would have worked in the first place or not. As I need to rely on something that would work 100%, we go with DELETE TAG ALL and recreate them all after. I never used REINDEX since the debut I was working with the tags.

I want to be clear... I have nothing against rebuilding indexes.
I do have something against a broad statement that "REINDEX IS USELESS".
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.

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.

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.

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.

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.

cheers