Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
MDot / By design
Message
De
04/01/2004 18:52:23
 
 
À
04/01/2004 16:23:49
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00863704
Message ID:
00863742
Vues:
35
Hi Jim,
>Do you think it would/could have effect (executing without a table selected as much as possible) on Fox's renowned speed?

I haven't any measures at my hand right now, but when a table is selected, it's fields are checked first. If no table is selected, reading will have to be done through the alias.fieldname syntax. Redirecting this way should have similar effects to with ... endwith: if many operations are done on the alias/table, selecting it once should be faster. Since changing the selected table also has a penalty (same as with ... endwith) it shouldn't be done for 1 or 2 operations only, but if many operations are needed, it sure helps.

So if i know beforehand that intensive work has to be done on one particular table, I make sure it is selected AND I access it's fields without the alias. So the question (for me) would be: Since working without a selected table is only a (strong) "should" rule and not a "must", it will be broken sometimes. Should I build the stability of my app on this rule or teach myself correct "MDot-Behaviour" ?
IMHO the seond approach is better, ***and*** VFP could even help me!

One further thing: sometimes (framework code) the alias gets set / defined at runtime and is a property in a data access object. It is ***far*** faster to select the table once according to that property than always have to eval() or even ¯oexpand. This is NOT my favorite way of doing things, but I've seen it sometimes (and hated it). But your approach would be costly in terms of performance, if this kind of data access is used.

The persistent, normalized application data will not be affected much, but business validation, special GUI rules and similar state mechanisms could be affected more.

The fox can be fantastic if the problem area is right and it isn't mistreated. OTOH, if a wrong approach is used, the penalty can be far greater than in other languages. Since there already *is* a way to do it "right", why add more rules on top ? But you are totally correct, the documentation is pathetic. in this case.

my 0.02 EUR

thomas
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform