Jojo to your example when I'm talking about parameters I'm saying to use params when calling SPT, of course SP's use parameters, now to you example if you have a web app where you enter the client name and want to return a list of clients that have that name are you going to create a SP for that?
I will not that I can tell you, but what I will do is use the client name as a parameter instead of concatenating the SQL and saying "...where clientname = '" + clientName + "'..." instead I will do "...Where clientname = @ClientName ..." and then will create the @clientname parameter, This is what prevents the SQL injection not the fact that I used an SP, instead of SPT, for me the SQL injection argument to use Sp's instead of SPT is a no brainier.
But then that's only my opinion and everyone is entitled to have their own.

>Hi Alexandre,
>
>Thanks for the explanation but don't you know that parameters are the core aspect of SP (my sentence might not be appropriate, e.g core aspect)? In SP, either you have input parameters or output parameters, so parameters is always there. If you allow your user to manually input SLQ query string to an input box without validating the input, I dont think you are protected with SQL injection attack even if you have a good data access layer especially in a web application.

>
>For those people who say that we can secure our database using role base, so how would we do then for a web base application?
>
>Your data access layer might be good but would it be better if you have also proper input valition?
>
>
>
>
>>Build your data layer class either using SPT or SP's can be of your choice more important to me is a good data layer that can be extended and can be fine tuned, What I use in my data classes is a service oriented approach, where each data class is responsible to deal with 1 or more then 1 table that are related, i.e. dataproducts class is responsible to get products from the database, insert/update/delete products , get product listings, and everything that is related to products in the database. Now in that class I may use SPT (ADO.NET) or call SP's isn't in my opinion that much of a relevant, Since everything in encapsulated on the dataclass if I have speed issues on a given method I can focus on that giving method and decide if is faster doing a SP or having everything in SPT, also I may end up creating .NET classes that will run inside SQL Server 2005.
>>About this I hear allot of developers saying oh that's evil, our DBA doesn't allow us to have access to do that on the database, but remember that may end up being doing already but using Compiled Store Procedures that are done in C++, run without any security and with no Control of SQL Server,The embedded CLR in SQL 2005 can be very powerful and save you allot of headshake, yes can create also some prbs but if an application is bad design then it can arise that also.
>>
>>
>>>>Jojo what protects against SQL injection is good programing not the use of SP, you should always use parameters that is what will protect you from sql injection.
>>>
>>>Ok, but how do you consider if one is a good programming practice? By what using proper ...?
>>>
>>>Please clarify..
>>>
>>>
>>>
>>>>
>>>>