>>>>The problem with a table with many fields / many tables is, VFP will first run against those, then against the list of variables. So for access mdot makes sense. But for assign a value or accessing something that simple could not be a field like a method or array there it does not much sense to use it.
>>>
>>>Lutz,
>>>
>>>Whether on the left side of a statement or in an expression, the variable is the same. I fail to understand why one would choose to reference it in different ways deliberately.
>>
>>Unused code is just bloat and adds nothing to usefulness. I can accept it speed up on several location. But makes code less readable. So I optimize? And mdot where there is no other way then variables could only make code slower. It must be dealt with.
>>
>>Best way for development is to skip mdot at all, it's super awkward (Just as adding alias for any field even if the alias is in scope. In fact it is aliasing memory variables) and in most cases VFP works without. It might be wiser to SELECT 0 and run variable based code without mdot instead of this oddness. In that case there is no field name, isn't it?
>
>That would be really odd. However, you're right. Fox will choose a field name over a variable of the same name. The more fields in the table, the more it slows down. That is the documented behavior. Select 0 would work. What ever means you wish to use to avoid the behavior is up to you. You cannot guarantee that a timer won't switch the alias on you. I believe some version of Fox did not tolerate the m.object. syntax. I get used to the m. and I'm not a Nazi to tell others to do or not do it my way.
>
>Readability is a tug-of-way between you and the computer.

ACK. The timer (any event, for that) would be crappy coded. Hard is the focus problem on grids on long running code. But, using naming convention will only slow down. DBX command are a problem of it's own, but they are to be avoided for that.