While I can certainly see the advantages of using parameters for SQL queries, especially when dealing with datetimes and things like that, I\'m still unsure about parameters
Use a procedure.
Convert the statement to static SQL, placing the value of parameter into a local variable.
This does help !
No, it is not enough. It will do in a pinch, but it is a very weak alternative, and using parameterized queries or parameterized stored procedures is better, if your platform and/or RDBMS support either feature.
From
OWASP's SQL Injection Prevention Cheat Sheet
...this methodology is frail compared to using parameterized queries. This technique should only be used, with caution, to retrofit legacy code in a cost effective way.
There are more below
SQL injection — but why isn't escape quotes safe anymore?
Sql Injection Myths and Fallacies
SQL Injection after removing all single-quotes and dash-characters
If the user only needs read only access to the data then have the UI execute via a SQL user that only has read only access. Read only does not protect you from injection attacks - they can use it to view data you did not intend them to view but they cannot use injection to delete data.
Yes, .Replace("'", "''")
stops SQL injection to the same degree that parameterization does.
There is still double or reflective injection. For example, you can store
'; delete from orders'
in a comment field. If part of the database uses the comment field in dynamic SQL, it might run the delete instead.
I think you're getting an answer on the way as to why it isn't enough, but you also run into the problem of somebody forgetting to do a replace on a string. If you 'always' use parameters, this is less of an issue.