Hi Thomas,

Your assumption **may** be correct as regards the operation without a selected table being similar to the WITH/ENDWITH construct. It has always been my **GUESS** that they are different.
I base this assumption on two main reasons:
1) the field vs memvar behaviour has been there since the start;
2) the behaviour for WITH/ENDWITH has constraints well beyond that of the field/memvar mechanism.

In fact it would be my guess that an aliased field name offers as fast access as unaliased. And of course there remain those cases, as the language is presently written, that **require** a SELECT regardless.

I agree, by the way, that using m. is the secret to preventing this problem. But I rather like the idea of being able to minimized it's need AS WELL.

cheers

>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