The old way Xbase dealt with the "USE" areas (before the concept of an "alias" was created) was to use single letters to identify them: SELECT 1 = SELECT A SELECT 2 = SELECT B all the way to SELECT 12 = SELECT L THEN, there was "M", which was reserved for memory variables. (I don't remember if it continued with 14="N" or not)
These could be used as aliases are used now, since they didn't have aliases yet: SELECT 1 USE Customer SELECT 2 USE Order IF B.Ord_Cust=A.Cust_Num * Do this ENDIF
So, This can get confusing if you use single letter names for object variables, since a table in Select Area 1 that has a field "Name" in it can be referred to as "A.Name", while object "A" probably has a property "Name" that could be referred to as "A.Name". VFP prefers the Table reference over the memory variable reference. One way to remove this obfuscation is to qualify the object variable as a memory variable: "M.A.Name"
This can also often happen with unqualified references to memory variables in utility functions: if a utility function, say "GetToken" is called when the current table has a field in it "Length", then inside the function is something like: FUNCTION GetToken PARAMETER InString LOCAL Length .... Length = Len(InString) FOR I = 1 to Length .... ENDFOR .... Then, the for loop will NOT execute from 1 to the length of InString, but will instead execute from 1 to whatever is stored in field "Length" in the currently selected alias.
It is best to qualify every memory variable (though most of us are too lazy to do so) and AT LEAST use a prefix that identifies the variables type (which, in most cases, sufficiently differentiates the variable from any table field, as in "lcName" as opposed to "Name", but sometimes it isn't sufficient, as in "loCust" and "Locust")
A better way to code "GetToken", with all the wonders of VFP's improvements, is similar to the following: FUNCTION GetToken( lcInString ) LOCAL lnLength .... m.lnLength = Len(m.lcInString) FOR I = 1 to m.lnLength .... ENDFOR ....