David,

First you take a minorly significant comment and turn that itno the crux of the discussion.
Let me repeat again that the problem is that VFP7 SP1 does NOT remove bloat out of indexes whereas VFP6SP5 and FPD2.6 (and I suspect all relases in between) DID.

>Jim,
>
>>The 5 exclamation points were noting that it grew at all. It certainly wasn't expected to grow, even by one character's worth.
>
>Well you just have misguided expectations. The two CDXes were NOT built the exact same way in your two tests, so one should not expect the balancing of the B+Tree to be the exact same when it's built as records are added, compared to VFP being able to read the table as a whole and build the B+Tree all at once. Frankly I'm kinda suprised that there is only a 32kb difference between these two constructions of the tree. It just points out that VFP does a pretty damn good balancing of the tree while building it during record inserts.

Yes, they were built differently. The real point is that it did NOT SHRINK, not that it grew.

>
>32kb out of an 88mb CDX truely is insignificant. If I had to guess I imagine those pages are consumed by original index headers that are just marked as unused once the tag is recontructed. Frankly I wouldn't be suprised if the CDX increased by a constant amount everytime you did a reindex.

Neither would I. Again, the matter at hand is that the indexes did NOT SHRINK.

>
>CDX bloat is mostly caused by VFP not recovering space consumed by tag deletion, and random record insertion over time. Yet your "test to end all tests" didn't cover these facets of the problem.

Now we're getting a bit testy! When did I say it was the test to end all tests. More importantly, though, what is the *real* difference between "random record insertion over time" and a stream of insertions where the TAGs in two of the cases are 'inverted' (as in generated in backward order)? And how often does one do deletion of a specific TAG in an application with 2 million records in it?
Please, be my guest and run some tests of your own that you will qualify as test to end all tests.

Maybe you missed the fact that the same sequence run in VFP6 did REDUCE the .CDX size from 52 meg t0 46 meg?
>
>Were in my post did I say that I didn't think you should report this? No where. All I commented on was the magnitude of the problem and that it IMHO didn't warrant a !!!!! alert.
>
>I'm not going to enter another time wasting thread, bitching and moaning about the inability of the outside world (which includes me) to see the recorded bug list that exists inside MS. I was only adding to the thread information that I got from the MVP newsgroups that in fact MS was aware of the doubling size problem.

I reported a bug (as I perceived it) here. I did not mention VFP Bug List at all. I do not frequent Compuserve, so knew nothing about the discussions there. And in any case those discussions, apparently, were about a different problem - that .CDX files under VFP7 SP1 are about double in size from those of prior versions.
It doesn't matter that they may have the same "root", and that remedying one might well remedy the other.

>
>Use the new list put together here on the UT to alert the world of the "bug" that I think is just a "by design" way the CDX works.

I don't know of such a list here on UT. Have I missed that too?
I would realy like to hear how a .CDX that will shrink when run using REINDEX and VFP6 SP5 and does not shrink running REINDEX in VFP7 SP1 is a "by design" happening.