>Most indices should be built at design time, so this is very likely an architectural issue.
>
>However, the Visual Extend framework dynamically creates temporary indices, allowing the user to to sort on two or more columns, for example. I don't complain about this, because of the enormous flexibility it offers - however, the developer that uses the framework should be aware of this, and use p-views for the child part of a parent-child relation (not only because of the indices, but mainly because of serious performance problems with filtered grids).

I'd agree building indices on temporary cursors is ok, because the temporary cursor is not shared.

>
>>Hi all.
>>
>>I'm wondering if you'd consider this an architectural issue or something else. Please tell me what you'd call it.
>>
>>I found a piece of code in an otherwise multi-user environment that builds a .IDX on a shared file. The IDX was filtered and used to access a subset of 5 million records. It took several minutes to build, but the users didn't mind that.
>>
>>I tripped over this issue while debugging. I only needed to change the code to SET FILTER using existing keys instead of INDEX ON to get the same effect in seconds.
>>
>>To me building an index should be a maintenance issue, not a part of regular processing.
>>
>>As far as I know, VFP on the client PC reads the table on the server to produce a set of keys on the tmpfiles drive. If the tmp files are on the server the keys are sent to the server. These keys are then re-read by the client PC and sorted and rewritten to the tmpfiles drive. Then this code would begin to access the data. That's 4 trips for the key data.
>>
>>Conversely, VFP on the client PC uses Rushmore to read the keys from the server into a ram-resident bitmap and this bitmap is used to access the data. That's one trip for the key data.
>>
>>It seems like a multi-user system should not employ single-user architecture?