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

Yeah but even then the remote server better support some mechanisms for named parameters :-) Which can be a pain in the ass having built a few of those 'passthrough' type remote servers, but it has to be done to avoid odd

SqlPassthrough, Remote Views and DataAdapter also all support the ? syntax so this is well supported through the Fox eco system. There's simply no excuse for passing strings in a SQL statement for data IMHO. It's too bloody risky.

RvBoy - now that's a blast from the past :-)

+++ Rick ---

>>>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...
>
>
>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. ;-)