This is a feature (you've been working on it for months, of course) which you can add to the app for your client and you can impliment it for an additional [$ place dollar value here] ;-)


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