I don't think you're right on this one (if you were, it wouldn't make sense at all that SQL parametrized statements still could work with object properties or, broadly, with a VFP expression).

Have a look at SQLPREPARE() help:

"All parameters in the WHERE clause must be defined before SQLPREPARE( ) is issued. For example, if the parameters are variables, the variables must be created and initialized before SQLPREPARE( ) is issued."

If that is not clear enough, in the help on parametrized views:

"The parameter name you provide is evaluated as a Visual FoxPro expression. If the evaluation fails, Visual FoxPro prompts for a parameter value. The parameter value supplied is sent to the data source as part of the SQL SELECT statement."

I think it's quite clear that the parameter for any kind of a SQL prepared statement is a VFP expression.

Even in the case of output parameters, what VFP expects is the identification of something that can store a value: a variable, an item of an array, or an object property. Here it is the example of the help file for input/output parameters rewritten so that the output parameter is a property of an object:

CLEAR

m.lnConn = SQLCONNECT()

IF SQLEXEC(m.lnConn, "CREATE PROCEDURE sp_test @mult1 int, @mult2 int, @result int " + ;
							"OUTPUT AS SELECT @result = @mult1 * @mult2") = 1
	m.loObj = CREATEOBJECT("Empty")
	ADDPROPERTY(m.loObj, "result", 0)
	? m.loObj.result
	SQLEXEC(m.lnconn,"{CALL sp_test(2, 4, ?@m.loObj.result)}")
	? m.loObj.result
	SQLEXEC(m.lnConn, "DROP PROCEDURE sp_test")
ENDIF

It will output

     0
     8,00

>Hi Antonio:
>
>If you open VFP Help and, on search tab, you write "sql and parameters", you will find that Dragan is right,
>Even if using properties (like "?This.Parameters.id") may work, they are intended for variables, and there is reason for this. If you look at "Using SQL Server Input/Output Parameters" chapter, you will find this between other examples:
>
>

>resultCode = SQLExec(connHand, 
>"CREATE PROCEDURE sp_test; 
>@mult1 int, @mult2 int, @result int; 
>OUTPUT AS SELECT 
>@result = @mult1 * @mult2") 
>

>
>or this one:
>
>

>resultCode = SQLExec(connHand, ; 
>"{CALL sp_test (2, 4, ?@outParam)}") 
>

>
>Some variables are for input and output, which means that the value can be replaced, and this won't happen with properties.
>
>And in this chapter, the "Defining Parameters" section states this:
>
>"When you implement input/output parameters, define the Visual FoxPro variables you want to include in your SQL pass-through command before you use the variables in the SQL statement"
>
>As you see, it mention "VFP variables", not properties. May be properties work for "input only" data, but I'm not sure of the special cases of this use.
>
>
>Regards.-