>What happens is that SQLExec can't find This.Parameters("id") in the prepared statement, and therefore prompts for its value. As you can see, the item is accessible in the someMethod context, as it should. In a first reading I couldn't find a reference for this in Tamar's paper Tore pointed to me, but may have missed it, of course.

Works this way:

	FUNCTION BuildQuery
		SQLPREPARE(THIS.REMOTE, "SELECT * FROM " + THIS.TableName + ;
			" WHERE " + THIS.RowId + ' = ?lnId')

	ENDFUNC

	FUNCTION someMethod

		MESSAGEBOX(THIS.PARAMETERS("id"))
		lnId=THIS.PARAMETERS("id")
		SQLEXEC(THIS.REMOTE)

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.