>>>>Totally agree.
>>>
>>>Acknowledging that all this does come down to personal preference, choosing to not use "m.", for whatever reason, is similar to being so confident that your own revolver is not loaded that you happily put the barrel to your temple and pull the trigger 6 times.
>>
>>I say, Jim, steady on! I've never used m. and never got outside a bullet for it. Am I wrong in saying xBase is the only language that uses this and all the others seem to get along OK without it?
>>
>>Cheers
>>
>>Terry
>
>The difference, as I'm sure you know, is that in VFP you can have fields and variables that may have the same name and can be referenced the same way in code. When that occurs, it causes an ambigous reference. Because VFP is a data-centric language, when a field exists with the same name as a variable, the VFP rule is that a field takes precedence over a memvar to resolve the ambiuous reference. The only way in code to differentiate a memvar from a field with the same name is to use m. An exception to this rule is when it is an assignment, because you "replace" a field and "assign a value" to a variable. When the program logic is expecting the value to come from the memvar, but the contents of the field is read instead, unpredictable errors can occur.
>
>When I write code, expecially reuseable functions and such, I don't always know who where it may be used and what tables may be open. Unless you use a variable naming convention that guarantees that you will NEVER have a field named the same as a variable, m. is your only defense.

Thanks, Elmer. Like you said, as you're sure I know... As had been said, in this thread, the use of variable naming conventions ( e.g. lcCustName for CUSTOMER.CUSTNAME, lnUserID for USER.USERID, etc), which I strictly adhere to (except for using good-ole "I" for loops) would seem to obviate the need for such differentiation. Whatever, I've never (knowingly!!!!) been bitten. As someone else has said, always using the alias when referring to fields doesn't hurt, and further clarifies the situation. Some other languages you have to do this anyway.