Jim, thanks for the info.

Another question please :

I don't have VFP7 running myself, but was planning to do so within due time;
Is a VFP5/6 indexed index compatible with VFP7 ?

I mean, in our situation the size of dbf-index is about 1-1, and when from now on all indices will be twice as large, the whole database will be 50 % larger, right ?
A lot of our users have a 40GB+ database, which will grow to 60GB then. It surely needs some new harddisks here and there ...

When all is compatible, I'm thinking of the REINDEX to be done in 5/6.
I know, rather stupid, but my idea anyhow.

And, is it confirmed that this happens with INDEX ON too ? This question, because it is a known fact that a REINDEX of one index tag only (out of several existing) will let the CDX file grow "unarbitrairy" anyhow.
So we never use REINDEX and INDEX ON only.

Thanks for any help.

Peter





>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