yep - an area they overlooked when they made other improvements to the text.
You know, for instance, that CDX bloat **is** eliminated by REINDEX (when the command has no bug in it < s >).



>The Hacker's Guide™ to Visual FoxPro® 7.0 says about REINDEX:
>
>This command regenerates all open indexes in the current work area. It sounds like a really useful command and we've been known to use it occasionally. But it has no place in an application. If the index header information is damaged, REINDEX leaves the damage there—it doesn't fix it. Also, it causes "CDX bloat", because it doesn't overwrite the space used in the CDX file by the former indexes. Instead, it marks those indexes as not being used anymore and adds the new ones to the end of the file. We've seen CDX grow to many times the size of the DBF file simply by repeatedly using REINDEX. For these reasons, it's much better to delete all the tags and re-create them from scratch. (But see our comments below.)
>
>>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.
>>
>>Now, my only guess on this problem by now is that the .CDX inquestion is not a "structural" index, but I freely admit thatit is a VERY long shot indeed.
>>