>Mike,
>
>You are deluding yourself if you think that ?x is less susceptible to SQL injection attacks.

There's a lot of delusion and paranoia over SQL Injection Attacks, but it's not me.

Here, let me help you:

Create a table called tblTest with a char (50) field called test_name. Add some dummy records to it. Just for fun add this text as the test_name of one of the records

'';DROP TABLE tblTest

Now run this...

STORE SQLCONNECT('db', 'userid, 'password') TO gnConnHandle
IF gnConnHandle <= 0
   = MESSAGEBOX('Cannot make connection', 16, 'SQL Connect Error')
   RETURN .F.
ENDIF

LOCAL lcName
*Simulate user input.
lcName = "'';DROP TABLE tblTest"

*Dynamically build a where clause consisting of named parameters.
lcWhere = "where test_name = ?m.lcName"

*Dynamically build the SQL.
lcSQL = "select * from tblTest " + m.lcWhere
?m.lcSQL
SQLEXEC(m.gnConnHandle,m.lcSQL,"c_PersonList")
BROWSE
=SQLDISCONNECT(m.gnConnHandle)

The profiler showed that this executed...

exec sp_executesql N'select * from tblTest where test_name = @P1 ', N'@P1 varchar(21)', ''''';DROP TABLE tblTest'
I got back the record with this

''';DROP TABLE tblTest
as the test_name field.

>
>It's a fairly high cost in the overhead of VFP communicating parameters to ODBC, compositing the SQL string yourself runs quite a bit faster.
>
>>I would never consider testing that. If MDOT ;) lnPercentage came directly from the user, that would be the dictionary definition of a SQL Injection Attack. Passing the value as a parameter excludes the injection attack.
>>
>>I thought passing the parameter in both cases validated the test by keeping the two processes more alike. Agreed?