>>And in your case you already have the variables anyway. Not only is it easier to write it's secure with no possibility of SQL Injection for the variables passed.

>>cSqlInsert = "INSERT INTO EMAILSEND (FROM_NAME, FROM_EMAIL, TO_EMAIL) values " + ;
"(?lcSendName,?lcSenderEmail,?lcRecipientEmail)"

>>You just have to make sure that the variables you use are in scope when the actual SQL statement executes.
>>I thought we were past this 15+ years ago. Hmmm...

I think his issue might be that he wants it to execute at a remote server- by passing a string for macro substitution.

If so, another possibility would be a proc at the server that extracts variables from the message (param1, param2...param9) to use as parameters in the passed SQL string. Both techniques do create a risk of injection by malicious messaging, though.

Not directed at you, but for completeness: tor remote data there's two big advantages of parameters apart from sql injection-proofing and handling of quote characters:

1) In SQL Server, a parameterized query is cached to deliver almost Stored Procedure efficiency on subsequent uses; and

2) Date and datetime can be a pita when concatenating queries for different databases, esp Oracle. But parameters encapsulate that completely.

Maybe it was 15 years ago that an irritating anonymous poster called "RVBoy" used to boast that VFP's Local/Remote Views deliver all these benefits and have since 1995. ;-)