>>>>>You mean in case there are table fields named lcFieldName, lcValue, or lcAlias? IMO anyone who would name fields that deserves all the trouble they get, hastening their transition to driving a cab for a living ;-)
>>>>
>>>>Yes,
>>>>And I think anyone who doesn't use MDOT deserves all the trouble they get either:) MDOT is part of the language and it should be mandatory. You are saying "anyone who would name.." but why are you thinking in the context of English. How do you know that 'lcalias' doesn't constitute a perfectly valid field name in Turkish or in another language:)
>>>>
>>>>Actually what I think is, if I wouldn't use MDOT here then I wouldn't use anywhere else and sooner or later get hit with not using MDOT. On another forum I wasted my time showing not using MDOT is unwise. Nay sayers, as it turned out, doesn't even know how VFP treat variable and fieldnames in different contexts.
>>>>
>>>>Cetin
>>>
>>>OK. You all have convinced me. (Yes, I do take advice, sometimes). Using m. prefixes is a small enough price to pay for even a marginal increase in code safety. We all know how even the tiniest slip-up can bite.
>>
>>Speed is another increased feature.
>
>How much speed are we talking about -- only a few milliseconds? I would think it would depend on how many open tables in the current session and I am not sure but I would expect that the table field names are cached. So the first time a variable is referenced, VFP has to look at all table names, then after that it is cached. The delay would be on the first variable name to not use MDOT and very minimal after that. I would be curious of any bench marks that shows above a second delay in overall program execution.

OK. Wait a sec. Why do you care how much faster, as long as it is faster?