David,

Would not that problem be easily solved by keeping as much as possible in RAM, then writing to TEMP files as needed, and at the end of it all write the .CDX data as it is structured today.

This would surely be much faster (or of equal speed when only 1 index is involved) than todays method and sounds to me like a suggestion one of you blue-enveloped folks should consider forwarding to the VFP team.

Cheers,

Jim N


>Rich,
>
>This will build all the indexes at once, but the real penalty is that the internal stucture of the CDX will be highly fragmented. Meaning that nodes of the B+Tree for each key will be spread throughout the whole file. This will cause lots of additional I/O time to read a key when rushmore needs it. If an index is built on the whole table at once the key occupies one contiguous space within the CDX. I think (untested assumption) that the CDX file size will be smaller becuase of the reduced fragmentation.
>
>>Seems to me that this may be faster (and close to what Ken was asking for) if you changed the process to:
>>
>>1. Build temp table from definition
>>2. Index temp table (define indices before import)
>>3. Import new data (Fox updates all indexes simultaneously in background)
>>4. Rename old table
>>5. Rename temp table to live table name
>>
>>This is untested, just brainstorming, and may be considerably slower, not faster, for all I know. In fact, I may have read tips from various experts (Goley?, Hennig?) that my suggestion is the bad way, and Ken's process is the fast way...