Mike Yearwood
Toronto, Ontario, Canada
Information générale
Catégorie:
Codage, syntaxe et commandes
Titre:
Architectural no-nos
Versions des environnements
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?
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement