I always use m. for variables when it's required. But in this particular case we wanted to shorten and simplify the code. Otherwise I would leave my original code where I was testing for existance of the field and building Insert command as a text variable.

>>Sorry, I've fallen into the same trap as lately with Borisslav. Here is my response:
>>I switched to nI_Dept, nM_Dept for better clarity. BTW, your idea works.
>
>Not many developers use this feature,
>but FoxPro has been drawn really to use
>this feature.
>But when SQL it is added to VFP,
>this feature it is become a trouble.
>
>If you look into my real code,
>the more frequent pattern is "m.",
>and every SQL's fieldname is fully defined;
>not for speed but for "correctness".
>
>If you make a typo and the program
>uses a variable to the place of a field,
>you can corrupt the customer's data,
>and when the customer find the bug,
>you become crazy to find it,
>and the recovery
>of the the customer's data
>probably becomes impossible
>
>A example:
>

>CLEAR ALL
>aab = 1
>
>CREATE CURSOR BYBY (AA I,aab i)
>APPEND BLANK
>Test()
>
>CREATE CURSOR BYBY (AA I)
>APPEND BLANK
>Test()
>
>RETURN
>
>PROCEDURE Test
>
>&& this works but it is a Developer program error
>SELECT aab f1 FROM byby		
>
>&& this is the correct version for a variable
>SELECT m.aab f1 FROM byby	
>
>&& this is the correct version for a field
>&& it fire a error when field aab don't exists
>SELECT t1.aab f1 FROM byby t1