Funny you should suggest this, Doug...

After Christof's latest to me I tried what (effectively) you are suggesting.

My last run with my big test table was a REINDEX using VFP6, and it had left a .CDX of approx. 44mb.
I recompiled the REINDEXing program under VFP7 and ran it against the VFP6-created table/.cdx and the .CDX came out at 88mb.

An actual "COPY TO" in the desired order won't, I *think*, prove much else because the table records each have 4 indices where two of the fields were deliberately generated descending and two properly ascending.

I do have the time right now, and the inclination, so I'll give it a shot anyway using VFP7SP1. My hunch is that the 16-byte CHAR key will prove more useful here than either of the INT keys.

I'll let you know.



>Jim,
>
>Out of curiosity...
>
>Why don't you try something (if you have the time & inclination) that might shed a little light on this. Once you have reindexed the table do the old COPY TO stuff and use the new table that has the records in the new physical order. Reindex that table's tag and see if that does anything. I'd be curious to hear whether or not this shrinks the CDX down.
>
>Of course, we optimists will now have to start speculating why this change took place. Maybe they're going to give us more table space... (he says TIC seeing if anyone will take the bait.. <g>)
>
>
>
>>Thanks for that, Christof. I can sleep much easier now.
>>
>>In this age of very large tables I would guess that such a change is still unhelpful, though if it was this that formed the basis of fixing potential index corruptions then it may indeed be necessary. If the latter is the case then this is again an area where some notice would have been desireable.
>>
>>I wish that I had the time to visit Compuserve (and several others), but I don't and so rely on UT for all of my "news". I hadn't seen this mentioned until you did so.
>>
>>Thanks again
>>
>>
>>
>>>Hi Jim,
>>>
>>>>>All this adds up to something possibly being seriously amiss in the most fundamental area of VFP.<<
>>>
>>>What had changed is the algorithm that handles an index node when a node is filled. Previously, VFP created a new node and continued writing there. Now VFP splits the existing node into two nodes. This results in a larger number of half-full nodes and an increased size between 0% and a little less than 100% compared to the previous index size. The exact increase depends on the order in which records are added to the index. The biggest increase in size occurs when data was ordered, which is why REINDEX has such an impact.
>>>
>>>The new behavior has negative influence on the size of CDX files and performance. But it doesn't have any negative impact on stability and certainly does not cause data corruption. In fact, SP 1 fixes several bugs that caused index corruption and most likely the current behavior is the result of a bug fix.
>>>
>>>In any case, this bug has been discussed on the CompuServe forum several times and in the past I have posted there more detailled explanations of what is going on.
>>>
>>>Christof