Again, my problem is that the APIs for parameterized prepared statements in SQL servers are often <i>ludicrously awful</i> which leads programmers to throw up their hands for non-trivial SQL queries and just say &quot;screw it, I&#x27;ll just concatenate strings together&quot;.<p>Which could have easily been avoided if the APIs weren&#x27;t crap, or if the API had exposed a method to say &quot;escape all special characters in this string because it&#x27;s getting concatenated into a query&quot;.<p>I mean, I can&#x27;t count the DB&#x2F;client-language APIs where writing a query that involves an IN clause with a provided array so that [&quot;foo&quot;, &quot;bar&quot;, &quot;baz&quot;]<p>became<p><pre><code>    SELECT * FROM MyTable WHERE Name IN (&#x27;foo&#x27;, &#x27;bar&#x27;, &#x27;baz&#x27;)
</code></pre>
without writing a non-trivial amount of fiddly code to handle building a list of parameters.<p>That&#x27;s an obvious use-case, but writing it in a parametric format is a gigantic PITA so developers just concat strings.  It&#x27;s not right but it&#x27;s the expected outcome of a bad interface that drives people away from the best practices.