Whew - make a joke and get an essay :-) Rich, you've made some points we should all pay attention to - I know that after the aforementioned problem *I* am paying more attention to assigning identifiers!

Your point about self-documentation is one we should all pay attention to as well. Even if we're looking at our own year-old code it can be hard to remember what variables we assigned.

Thanks,
Barbara

>OK, I'll define possible ambiguity. Anywhere in a command where the position of the identifier doesn't force (V)FoxPro to interpret it as either a memvar or a field in the current table.
>
>For example, in:
>REPLACE ThisField WITH m.ThisVar
>ThisField is not ambiguous, because in that position in that command you can only have a field. ThisVar without the m. would be ambiguous, FoxPro would have to first check if there's a field named ThisVar in the currently selected table, then check for a memory variable.
>
>and in:
>ThisVar = ThisTable.ThisField
>ThisVar is not ambiguous, because in that position in that command you can only have a memory variable. ThisField without ThisTable. would be ambigous, FoxPro would first check for a field named ThisField in the currently selected table, then check for a memory variable with that name.
>
>I think that's a pretty clear black-and-white definition, and it's a hard/fast rule in my programming style to put the alias or m before any possibly ambiguous identifier. (Sometimes I also put the variable/table designator before non-ambiguous identifiers to be "self documenting".)
>
>FWIW!