Jim,

This subtree of the thread evloved into APPEND a LARGE number of records to a table with tags already setup, and my entrance into the thread was give more details about why that adversely affects the CDX file. It does achieve the goal of allowing VFP to create all the tags for a record without having to read the actual table more than once. The tradeoff is decreased CDX performance becuase of disk latency, seek and I/O time.

It's pretty hard to estimate if the dbf I/O time to reprocess each record to read the field while index generation is being performed outweighs the time it takes to build the B+Tree. And I'm not certain if trying to keep 183 (the extreme case mentioned in Kenneth's original post) index trees in memory would actually become slower than building them one at a time.

If the table was part of a DBC all of the index information is there, so it would be handy to be able to do something like SUSPEND INDEX, APPEND, REINDEX.

Despite all the grumbling you do about foxwish@microsoft.com it is a fact that the more people that suggest a given improvement the higher up the list it will go. And just because something is at the top of the list doesn't guarantee it'll get into the product within the next N revs.

>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.