>Fred, have you looked at the example I posted? The only 'sin' committed by the code that got a global by reference was to cause an implicit refresh of current relations by calling SET DATE, yet this caused a completely different, unrelated subsystem - symbolized by the RELA_() function - to break since the global was no longer visible (type([m.g_uTest]) == 'U').
>
>In some cases the problem can be avoided by rewriting the interface from
>
>

>function ModifyFoo (roFoo)
>   * ...
>   roFoo = m.oNewFoo
>   return <whatever>
>
>* elsewhere ...
>if ModifyFoo(@m.g_oFoo) == <whatever>
>   * ...
>endif
>

>
>to
>
>

>function ModifyFoo (oFoo, ruStatus)
>   * ...
>   ruStatus = <whatever>
>   return m.oNewFoo
>
>* elsewhere ...
>local uStatus
>g_oFoo = ModifyFoo(m.g_oFoo, @m.uStatus)
>if m.uStatus == <whatever>
>   * ...
>endif
>

>
>But this means that the ModifyFoo() call can no longer participate in things like CASE statements and other conditionals unless a wrapper is written:
>
>

>function ModifyGlobalFoo
>   local uStatus
>   g_oFoo = ModifyFoo(m.g_oFoo, @m.uStatus)
>   return m.uStatus
>
>if ModifyGlobalFoo() == <whatever>
>   * ...
>endif
>

>
>Bottomline: the ModifyFoo() code has to be changed even though it does not deal with any globals directly, and the code that calls ModifyFoo() has to be changed one way or another. And the whole shebang just got a bit messier instead of leaner/meaner/cleaner during maintenance. ;-)

There will always be "gotchas" in a product as complex as VFP. I can't really remember the last time I've used a relation, cursors have been so ingrained in my way of thinking, I rarely even think of using relations anymore. I'm sure that other scenarios exist that can cause similar behavior, I've probably even run into them. I just change my code and move on, it's just not likely that something so base in the VFP code will change before I can "fix" the "problem" in my code.