>>>I'm using the following UPDATE command in a form method:
>>>

>>>LPARAMETERS ;
>>>	tiSessID ;
>>>	, tiSitNo
>>>
>>>UPDATE Grads SET ;
>>>	cFName = ThisForm.txtcFName.Value ;
>>>	, cMInit = ThisForm.txtcMInit.Value ;
>>>	, cLName = ThisForm.txtcLName.Value ;
>>>	, cStreet = ThisForm.txtcStreet.Value ;
>>>	, cCity = ThisForm.txtcCity.Value ;
>>>	, cProvince = ThisForm.txtcProvince.Value ;
>>>	, cPostCode = ThisForm.txtcPostCode.Value ;
>>>	, cPhone = ThisForm.txtcPhone.Value ;
>>>	WHERE iSessID = tiSessID ;
>>>		AND iSitNo = tiSitNo
>>>

>>>All of the target table columns and form controls ( .txtc*.Value) exist. The control values are not NULL.
>>>
>>>When run, I get an error "Alias 'TXTCFNAME' is not found".
>>>
>>>If, for test purposes I replace the ThisForm.Control.Value(s) with string literal(s) the command works fine.
>>>
>>>Is this a known problem, that UPDATE - SQL can't make use of form control properties this way? Any workaround other than declaring local temp variables to hold the values? TIA.
>>>
>>>UPDATE: never mind - it's right in the VFP Help that you can't do this, and that you need to use local variables. One place where good ol' REPLACE helps out - it doesn't complain about using object properties ;)
>>
>>Except that, as I keep trying to get across, by using properties, you are already taking a performance hit. Also you're leaving yourself open to worse, even difficult to debug, potentially drastic hits. Just add significant access/assign methods to those properties and watch things crawl.
>
>In this case I needed something that worked. Using object properties works fine with INSERT - SQL and SELECT - SQL, I was a little surprised they won't with UPDATE - SQL. Seems to me an inconsistency in the language, or maybe something was never finished in the implementation of the latter.
>
>Your points about performance are well taken but in this case don't matter.

Well, not that you'll use TEXTMERGE, you'll have a consistent and I'll say extensible way to handle all your SQL. :)