>>It's much cleaner to use TEXTMERGE

>>
>>TEXT TO cSQLStatement TEXTMERGE NOSHOW PRETEXT 15
>>SELECT column1, column2, "<<alltrim(object1.object2.property1)>>" as column3
>>FROM cursor1
>>INTO CURSOR cursor2 READWRITE
>>ENDTEXT
>

>
>Sergei,
>
>my general case is that SQL statement could use both object properties as well as columns of the original cursor to create new columns in the destination cursor, for example:
>
>

>cSQLStatement = SELECT column1, column2, alltrim(object1.object2.property1) as column3,;
> alltrim(cursor1.LastName + cursor1.FirstName) as FullName FROM cursor1 INTO CURSOR cursor2 READWRITE
>
>&cSQLStatement
>

>
>Although object properties are constant, and the TEST TO approach would work, the same approach could not be applied to reference other columns (cursor1.LastName + cursor1.FirstName) to create a new column. Therefore, it looks like I am stuck with the macro substitution. Therefore, the problem still remains: macro substitution seems to mess-up the object properties, or am I doing anything wrong?
>

Hi Igor,

It has nothing to do with macro substitution. IMO, the problem is that '.' (dot) is used for 'object.property' and for 'workarea.field'. It leads to ambiguity which VFP doesn't handle very well in SQL commands.
My sugesstion to use TEXTMERGE doesn't eliminate macro substitution but makes building quieries easier and simplifies maintanance. It also allows to evaluate constatnt values, like properties, at the time when query is build which could be a good or bad thing depending on your requirements but it certanly eliminates the problem with oobject properties references in the field list.

TEXT TO cSQLStatement TEXTMERGE NOSHOW PRETEXT 15
SELECT column1, column2, "<<alltrim(object1.object2.property1)>>" as column3,
    alltrim(cursor1.LastName) + ", " + cursor1.FirstName as FullName 
FROM cursor1
INTO CURSOR cursor2 READWRITE
ENDTEXT
&cSQLStatement