Using parameters does not guarantee there can be no SQL Injection attack. It can help eliminate it, but if the SP then dynamically creates a query, update, etc, SQL injection can happen. Bottom line, you still need to properly write the SP.

>You can handle some situations better on the server and others on the client.
>
>For example having a really complex set of updates and deletes across large numbers of records is good on the server.
>
>Having a single record update stored procedure is silly. There's no way that will be faster than a similar update statement. In a sense the update command itself is a parameter passed to SQL's command processing "stored procedure".
>
>The question is which is more flexible - a dynamic update statement or calls to fixed stored procedures? Either way you have control over the queries no matter if you write them in SPs or write them in VFP / ASP.
>
>As for SQL Injection Attacks, if you pass user input as parameters, that input CAN NOT be used for an attack.
>
>lcVar = "un-edited un-scrubbed raw user input"
>sqlexec(lhConnection,"select * from tblTest where test_name = ?lcVar")
>
>No matter what you put in lcVar, there can be no SQL Injection Attack.
>
>The profiler will show this:
>
>exec sp_executesql N'select * from tblTest where test_name = @P1 ', N'@P1 varchar(21)', ''''';DROP TABLE tblTest'
>
>which means find records that have test_name = to what the user entered. It does not mean execute what the user entered.
>
>HTH