>>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.