David,

The *original* message was about creating/recreating indexes (in his case, on every field (ugh, usually)).
Your reply preceding this one seemed to be on the same topic. Now is seems to have switched to *adding records*. I don't think anyone is suggesting any change in how added keys (to an existing index) are to be handled.

I read your prior response as saying that the idea would cause a serious problem because (paraphrasing) building each index as you processed each record would undoubtedly result in extreme fragmentation. I agree with this, and simply posited the alternative that using TEMP files to keep each index separate *during* the building process, then putting each of those TEMP files into the newly created .CDX would result in a .CDX identical to todays.
In other words, as each record is read, each required index 'record' is kept in its *own* RAM structure, *each* overflowing to a TEMP file as necessary. Once all records are read, and thus all indexes known, they would be written from TEMP/RAM to the .CDX. No more fragmentation than is the standard today.

Sure, this would require some change in VFP. Two possibilities which come immediately to mind are:
1) Allow the INDEX ON command to have multiple specifications;
2) Have the 'interpreter' check the next statement any time a INDEX ON is hit, to see if the next is also an INDEX ON (until it is not) and then use all of them in the revised processing described above.

I'm sure that the VFP team can come up with the *best* way.

The point is, this is a high overhead process, and anything that can be done to reduce it is worthwhile. The VFP team ought to be presented with this suggestion for implementation consideration.
There is little sense in 'average Joe' submitting the suggestion since that is basically a waste of time and energy. But the blue-enveloped folk have "other channels" which possibly get some attention. Thus my suggestion that one of you might take up the cause.

Cheers,

Jim N

>Jim,
>
>There isn't much way around B+Tree fragmentation as blocks of records are added, it's just inherent in the data structure. And further file fragmentation occurs when multiple index tags are involved. There's not an "inexpensive" way of moving multimegabytes of cdx around on the disk drive either. You could potentially pad the tag space inside the file but then you'd have people complaining about increased CDX file size.
>
>>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.