>>When I write the code I will never have the problem of using the m.dot or not using the m.dot. My coding convention uses the above rules. However, when we use classes that the community has written now we could have potential naming conflicts between variables and fields. So having the compiler enforce the rules is preferable.
>>
>
>Just want to point out that the Hungarian naming convention isn't infallible. While it's a bit of a stretch, it's certainly possible to have a field name lOrange and a variable named loRange. I haven't gone hunting for other examples, since one makes the point, but I'll bet there are others that are plausible.
>
>In my view, VFP developers should always use mdot where there's any chance of ambiguity. That's even more important for tool writers since they have no control over the naming of fields in tables their users create.
>
>Tamar

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.