>>
>> You might be advanced enough not to be trapped with it but it's not
>> optional for robust code (+faster with loops).
>>
>
>Well with the "m" loops take significantly longer - at least the coding <bg>
>
>no, honest? Is there truely an advantage of Using "M." on normal variables? I remember this from my old DBASE and ARAGO-Times where we used it a lot. And I only use it with Field vars when using SCATTER MEMVAR
Yes there is at least one true undeniable advantage. For example consider your original function. Suppose you gave it to me and Im using it within my application. Think of code:
select myTable
if YourFunction(m.SomeVariable) = 0
It would error as soon as I have a field in current alias named same as one of your variables. You might never know how would I name my fields and I might never know how would you name local variables. Depending on a field like lnretval could never exists is not fair. What stops me from naming LoanReturnValue as lnretval:) Being faster in loops is a plus.
PS: If it errors I still could find and fix it, worse if datatype matches I might work with wrong values.
Cetin