Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
MDot / By design
Message
From
04/01/2004 18:52:23
 
 
To
04/01/2004 16:23:49
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00863704
Message ID:
00863742
Views:
36
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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform