>IOW, there are limits to how far the SQL statement parser can go when analyzing and replacing anything that's prefixed with a question mark. I think it's the use of "this" in there - that reference works inside a method or event, but the SQL statement is way out of that context. You can rely only on generally available things - functions, public and private variables, perhaps even methods of global objects.
>
>The parser is not too smart - it doesn't even know how to skip the comments, so if you ever have a question in your SQL, the question will break the statement:
>
>

sqlexec(h, "-- what happens now?"+chr(13)+"select @@version", "blabla")

>
>will give you the nasty "SQL parameter is missing" error.

Thank you, Dragan.

I see your point but I think this is not fully the case of missing or being baffled with This reference.

I rewrote the Parameters Collection class as Empty and the program works fine (that is, recognizes the parameter source):

	FUNCTION SetParameter
		LPARAMETERS tcId, teValue

		IF ISNULL(This.Parameters)
			This.Parameters = CREATEOBJECT("Empty")		
		ENDIF

		AddProperty(This.Parameters, m.tcId, m.teValue)
	ENDFUNC

	FUNCTION buildQuery

		SQLPREPARE(This.Remote, "SELECT * FROM " + This.TableName + ;
										" WHERE " + This.RowId + " = ?This.Parameters.id")

	ENDFUNC

	FUNCTION someMethod

		MESSAGEBOX(This.Parameters.id)
		SQLEXEC(This.Remote)

	ENDFUNC

And I know it's not a don't-call-an-object-method issue because I circumvent the problem by creating a local reference the This.Parameters Collection, not by putting the value of its items in variables.