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.

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.

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.

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.

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.