Removing embedded quotes may mitigate the risk of some forms of SQL
injection but it's best to use a parameterized command rather than
concatenating user-supplied values.   You don't necessarily need to use
stored procedures.

Here's a kinda contrived example that doesn't involve ' . You have a query:

SELECT ProductName FROM Products WHERE ProductID = ?

and someone supplies:

1 UNION SELECT UserPassword FROM Users WHERE UserName = 'Administrator'

Your code to escape ' won't really help much. You need code to validate that
the value supplied for ? is actually an integer rather than a string.

And so it goes on. Dan's suggestion of using parametised queries is a good
one - do that if you can. Trying to filter for known bad input is a losing
battle unless you spend some time (and continue to spend time) keeping up to
date with all the latest threats.

Cheers
Ken

Hi,

The best method of avoiding most SQL Injection attacks is to validate all
input and reject the entire input if any instance of bad or malformed input
is detected.  While I know this sounds harsh it is the only real way to
defend yourself against it.  Ensure that your variables are cast to the
correct type, ie numbers are numbers etc, dates are real dates.  The most
difficult type to verify is free form text.  The comments about using
parameteried queries or stored procedures is a valid point and will help
from the SQL backend.  Then of course there is character encoding.  Avoid
building dynamic queries as follows:

sql="SELECT * FROM mytable WHERE name='"+NameStr+"'"

As injection using the NameStr variable is highly possible.  In summary
ensure that the injection vectors (the input where sql injection takes
place) are validated to be true input.

NGS Consulting have some white papers on code injection that may be of
interest at http://www.ngsconsulting.com/papers.htm
Phil