>I totally agree. In my development of my Query tool, I ran across many times that both field names and even table names interfered with variable references. So, when in doubt, prefix variables with the 'm.'
>
>Once upon a time, there were the ability to address the table's alias with a letter ('F'). This was true for A thru J (10). 'M',being outside the range was safe for a reference to a variables. But, along came FoxPro (and others), and the whole alias thing changed. But, still, for backwards compatibility they should still work; up to 'J'.
>
>Point: Do not create object to single letter variables between 'A' and 'J'. The system will attempt to resolve them to the table level first. If there is a field in the work area with the same letter (ie 'a.field') then it will be used. Even if your intention was to address the object 'a'; oh well.

IMHO, mdot should be used wherever there is a memory variable. Its benefits are obvious and it can also prevent hard to catch bugs.

One letter objects and variables can still be used, provided you simply follow the best practice and prefix with mdot :)

-apart from resolving name collisions for certain, using mdot also increases the speed as everyone (well maybe not everyone) knows.

PS: (
In my foxpro life I have run into many mdot discussions and even was challenged in one way or the other. I supplied numerous codes that demonstrate the need to use mdot. None of the ones who object to using mdot could provide a single -just one single- code piece that shows using mdot is harmful in any way. The only funny objection is "readability" and typing 2 extra characters - actually using mdot not only increase the readability but also provides intellisense support :)
)