Also, just because it's a parameterized stored procedure it doesn't automatically mean that it's immune to sql injections (especially if you use dynamic SQL inside of those procedures). On top of that there are also dev related reasons why some choose not to use stored
<br>procedures in general. Here are a few reasons:<br><br>1. They slow down the development process making it harder to do the testing (overall application testing and the stored procedure testing).<br>2. Because of their procedural nature they are prone to code duplication (which some developers try to avoid).
<br>3. Integration / configuration management overhead managing separate stored procedures and the main application code. <br><br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Why don't more people just use Parameterized Stored Proceedures? Is it<br>> because there are implimentation issues or because people don't know<br>> about them? Whats your opinion?<br><br>I wonder that too. Also, why don't people just not write integer overflows?
<br><br>With the snark bit cleared, I'll point out: lots of projects use<br>stored procedures, but have some patches of functionality (like query<br>builders) that are easiest to write with raw SQL.<br><br></blockquote>
</div><br>