>>>>

>>>>cSqlUpdate = "update mytable set field1 = ?cNewFld1Val , field2 = ?cNewFld2Val where pk = 10"
>>>>lnResult = SQLEXEC( nSqlHandle, cSqlUpdate)

>>>
>>>Do the variables cNewFld1Val and cNewFld2Val have to be Private? I have them Local and they are in scope with the above command. But I am not getting results I expect. So, I thought maybe this is the problem.
>>>Please let me know. Thanks.
>>
>>Dmitry,
>>
>>I'll step in to reinforce what Dragan said, the variables you use must be in scope, being irrelevant if they are Local, Private, or Public. But I also would like to emphasize that a parameter does not have to be a variable. In fact, you should see it as an expression, and the value of an expression in VFP can be highly dependent on the context.
>>
>>For instance, in your case I would prefer to prefix the variable names with m-dot, to be sure the parameter value comes from a variable, and not from a field in the currently open work area.
>>
>>Consider this:
>>
>>

>>CREATE CURSOR TestCursor (TestField Integer)
>>
>>INSERT INTO TestCursor VALUES (10)
>>
>>LOCAL TestField AS Integer
>>
>>m.TestField = 15
>>
>>SQLEXEC(m.ConnectionHandle, ;
>>  "SELECT * FROM RemoteTable WHERE RemoteColumn BETWEEN ?TestField AND ?m.TestField;", ;
>>  "Result")
>>

>>
>>What is passed to the remote server is the SQL statement
>>

>>SELECT * FROM RemoteTable WHERE RemoteColumn BETWEEN 10 AND 15;
>>

>>
>>Of course, I'm not saying or suggesting that this explains the results you're getting, but hopefully it will make a bit more clear how you should evaluate the parameter, that is, the expression that follows ? until it finds the end of a valid expression.
>>
>>In the next statement, INT(m.TestField * (1 + RAND())) is at first evaluated by VFP and only then passed to the ODBC driver as a parameter, and sent to the server.
>>
>>

>>SQLEXEC(m.ConnectionHandle, ;
>>  "SELECT * FROM RemoteTable WHERE RemoteColumn BETWEEN ?TestField AND ?INT(m.TestField * (1 + RAND()));", ;
>>  "Result")
>>

>
>Hi Antonio,
>
>Thank you for clarifying and for the sample code. The reason I never use a prefix m. before a variable is because I am always careful in naming my variables different from fields or expression. But I agree, it does not hurt.

It hurts speed on setting (miniminiminiminimally)
but speeds code up on reading.... also only on reading danger of name clash, as you have to update or replace fields.