General information
Category:
Databases,Tables, Views, Indexing and SQL syntax
Doug,
I hope that this is what you had in mind:
Under VFP7 SP1:
Use subject table order by 16-char field...
TEST1
COPY TO a new table (just the DBF) then INDEX ON the fields in question.
TEST2
COPY TO a new table WITH PRODUCTION to create the indexes during the copy.
TEST1 resulted in a .CDX size of 100,990,464 as reported by FSIZE()
- an immediate REINDEX gave an identically sized .CDX
TEST2 resulted in a .CDX size of 88,145,920 as reported by FSIZE()
- an immediate REINDEX gave an identically sized .CDX
>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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only