Mike Yearwood
Toronto, Ontario, Canada
>Hi Mike,
>
>>I'm curious what stuff you've read. I hope it's not misconceptions about SQL Injection Attacks and the myth of better performance that's driving your decision.
>
>I've talked about it with some friends. I think (it is my first project using SQLServer, so I'm a newbie!) that using SP, I can handle my data better in addition to have better performance.
>
>But, I didn't starting it yet. I'm creating my database model. Do you have some suggestion for me?
>
>Important: The data will be access in local network and internet too.
>
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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only