Peter,

The primary argument that the change is not a bug is that several index-related bugs were fixed by VFP7 SP1.
However, someone over in the CompuServe VFP forum *did* make a statement that MS had accepted the "observation" as a bug.

What I do know is. . .
1) REINDEX prior to VFP7SP1 did shrink a .CDX when there was ONLY "bloat" caused by added keys (that is, not "bloat" caused by DELETE TAG operations, though those versions also DID remove such bloat).
2) A REINDEX under VFP7 SP1 of a table that was immediately previously REINDEXed using VFP6SP5 (and so was at its smallest possible at the time) did cause the .CDX to virtually double in size.

There could be something about distributing 'free space' in a .CDX that improves speed. But in and of itself, surely ALL REINDEX operations already did take care of redistributing nodes to optimize performance as well as to eliminate "bloat".

To my knowledge MS has NEVER made a public statement about the state of .CDX files after a REINDEX in VFP7SP1, so no one can know for sure. The statement on the Compuserve forum was second-hand information.

cheers

>>>Hi Jim
>>>
>>>Is the index growing, a bug in VFP7 SP1?
>>
>>Nobody knows for sure (not even her hairdresser). My guess is that it is a bug.
>>
>>
>>>
>>>John
>
>I read somewhere (here ??) that when a new index block is created, it's filled initially with only 50 % of the space possible. At that time of reading I interpreted the argument as stupid, for a thing we call a bug indeed. However, looking at all the manipulation VFP has to do in order to insert a new key somewhere, there can be much truth in the argument "speed". IOW, instead of shifting ranges of keys to next blocks, now it can shift within the block, until it is full. May be very much faster indeed.
>But all is just my guess of how things are working internally.