The app I inherited does this:

SCATTER NAME Tablename

So now, not only do I have to worry about fields taking precendence over vars, I also have to worry about aliases taking precendence over objects.

The only solution is m.object because I cannot rewrite the stupid choices made in the past.



>>>There is stuff that is unable to survive badly written asynched events.
>>>A
>>>

>>>REPLACE;
>>> Alias.Field WITH VALUE;
>>> FOR condition;
>>> IN Alias
>>>

>>>Will die silently, if async code sets the current workarea to something different then alias, but on EOF, as far as I remember.
>>
>>Actually, with the IN clause there, this one should be fine. Without IN, it's dangerous. Every REPLACE should include IN.
>>
>>Tamar
>
>Then this must be changed sometimes. There was a problem with active workarea at eof and using IN
>
>Anyway. No, one must not. If the code runs encapsulated (in a distinct DE) nothing will change work area. This happens only to code running in a form or DE bound to a form. What violates n-tier approach. One of the reasons to encapsulate data processing from FORM. (And FORMS DE in particular)