>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