>The attack vectors cited below, which are real even with parameterized SQL statements, are eliminated by a server side API creating the CRUD statements.
>So for SOME scenarios, there is reason to avoid parameters, as their transport mechanism might be subverted and the whole statement might be altered.
>
>
>>... There is zero reason to avoid using parameters.
>>
>>>>>Actually ***his*** source is safe against anything except for MIM attacks or total code rewite, which would succeed even in SQL parameter cases by rewriting the whole statement, unless there is further sanitizing server side.

Server side APIs hamstring external developers and users. I can't build a dynamic query and get the data I want, the way I want it if I can only execute simple API calls. While I recognize there might be a way to intercept the ODBC connection between an application and a database server and change the SQL going to the server, I can't get over the idea that it is called SQL Server, not SQL API server.