Christof,

That's a tid-bit that I hadn't heard before! In fact I found it hard to believe, given that I don't recollect seeing it mentioned here (UT) before this.
So I did a small test and the results were, to say the least, "surprising"! Here's what I did:

I compiled and ran a program under VFP6 that creates a large table (approx. 660,000,000 bytes) with 4 indices of which 2 were INTEGER and 2 were CHAR. Two of the indices were generated to deliberately create "bloat" by indexing each ASCENDING but generating their content in descending order.
The resultant .CDX size was: 67,280,896 bytes as reported by FSIZE().

I then REINDEXed the table (separate program) and the .CDX was reduced (as expected) to 45,712,968 bytes.

I then compiled and ran the identical program under VFP7 SP1.
The resultant .CDX size was: 88,113,152 bytes as reported by FSIZE()!!!

The REINDEX (compiled/run, separate program) gave a .CDX size of 88,145,920 bytes!!!

I remain surprised that this happens, though the 'proof' seems incontrovertable.

It also makes me wonder if the increasing number (at least in my perception) of messages here regarding 'corrupted index' might have something to do with this.

Got any more of these little jewels?

THANKS!!!!!!!


>Hi Ken,
>
>>Out of curiosity, what was the reason for the delay?
>
>Several developers refuse to upgrade to VFP 7, because SP 1 creates CDX files that are almost twice as big as before.
>
>Christof