Naomi, one other thing to keep in mind. Standardization is not an individual decision. That is usually already in place, and if not, standards are agreed upon by team involvement or in some cases, simply by the boss (the one with the decision making authority). Changing it may make it more efficient, but may break code elsewhere. Are you sure you have the authority to make those changes? I would discuss those type of changes in advance before implementing them - no matter how much sense it makes to do so. It is a surefire way to make enemies of your co-workers.


>>Hi Mike
>>
>>>>It's really funny. In the program that used by several developers my colleague put **** PLEASE DO NOT PLACE "m."s *** at the top and removed m. even from my procedures <g>
>>>
>>>That's not funny. That's plain stupid. Leaving them in will prevent errors and improve performance. Taking them out ONLY changes how the code looks in an insignificant way.
>>
>>I just jumped into this thread, so please forgive me if this is already brought up.
>>
>>What would happen when...
>>

LOCAL lcMyVar
>>
>>lcMyVar = MyTable.cMyVar

>>
>>Is this efficient and still avoids the problems and improves performance?
>
>Yes, it's efficient. I always add table aliases to avoid ambiguity. We're talking about lcVar = m.lcAnotherVar In this case m. indicates, that it's a memory variable and not a table field. Following strict naming convention reduces risk of running into table field to almost 0%. The performance difference would be visible only in lots of iterations...