Thanks again Jim. ***

About the REINDEX doing all : yep, you are right, and I guess I am confused with the tricks I tried in the past to have one index only reindexed. Possibly I used an Index On without deleting the tag concerned or so. It was some trick where A1 became A6 (first one not existing), and I was able to restore the normal sequence (all working out well, but leaving you with the larger file. Hmmm, which seems logical by now assumed that the old data would remain in there ...).

Peter


>Peter,
>
>Yes, INDEED, a VFP5/6 .CDX is fully compatible with VFP7 and a VFP7 CDX IS compatible with VFP5/6 (at least as far as some limited testing that I did showed).
>
>Remember, too, that ONLY the .CDX doubles in size, NOT the whole .DBF+.CDX. So yes, the 'database' (one .DBF + 1 .CDX) will grow by 50% assuming equal sizes of each to start.
>I would doubt that 40gig of data would grow to 60gig but I agree that it *could* happen.
>By the way, since it is impossible to REINDEX a single TAG there is no problem with "unarbitrary" growth (allowing that VFP7SP1's growth is not "unarbitrary").
>I honestly do not know the impact, IF ANY, of INDEX ON in VFP7SP1 as regards CDX size.
>
>I think that VFP7 SP1 is very very good and that you will find it most useful. Intellisense took me a bit of time to get used to, but it not only speeds my work now but it also reminds me of capabilities that I had 'forgotten'.
>
>
>
>>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