>>Walter, your convention does not prevent var/field name conflicts. Initially, you joined this conversation with the statement that your naming convention covers this issue, but so far, you only have shown how and why you name the table fields, which is the subject of another discussion. Coming back to the issue, can you guarantee that there is not (and that will never be) a variable anywhere in your code with the same name as a field in your tables?
>
>Isn't that the same question as: Can you guarantee that you never forget to write an mdot where it is needed to prevent a conflict?
>Of those two questions which one is more likely to occur?

I agree it could happen, but it's not the same. You realize that in your case the risk of conflict grows with every new table (or even query) that you add to your project, and with every new variable name. In other words, your risk of conflict grows no matter what (i.e. when you're coding normally). Mine, only when doing things wrong. Also, in my case there could be one or very few instances raising that risk. Whereas in a project not using mdot, the risk is everywhere.

>
>If you really want to know that answer I encourage you to go to VFPX and download some sourcecode and analyse it in detail.

I know what you're talking about. And that is why I wish everybody was using it, especially when writing shareable code. So, we need people like you to support mdotting, not discourage it.

>>*
>>Refutations for your examples:
>>* Yes, you should mdot your object variables to prevent cursoralias.field conflicts.

>How many developers are actually doing that ??

I don't know how many, though you've seen here responses from quite a few of them, all with great reputation in the VFP world. I do it because it makes sense to me, though I have to give credit to those who raised this issue long ago.

>Not applying it consistently only adds to the risks to forget to do it where needed. And if you need a very lengthy wiki topic on fox.wikis.com on where to apply it and where not, it is a good indication that you're waiting for mistakes and a false sense of safety. Hence my objection against that practice. Again look at the source code available on VFPX and the rest of the internet. You'll be surprised.

Well, then let's apply consistently. I'll have to go back to Cetin's question: Show me where it would be a problem using it, other than the small and short-lived inconvenience of typing m.? Compare that with the benefits of minimizing the risk of ambiguities.
*