Truthfully, SQL injection can be prevented by Parameterising your queries (look into ODBCParameters for instance) and your queries can be constructed such that these parameters cannot be SQL injected. For instance...
DECLARE @param varchar(50)
SELECT @param = ?
SELECT * FROM TABLE WHERE NAME = @param
is a safe method of doing internal queries with ODBC parameters. However, there are some advantages to using Stored Procedures:
- Complex SQL with multiple functions or cursors can screw up if used in an ad-hoc manner as some ODBC drivers don't know how to handle multiple query requests
- It separates the business logic from the database calls. This allows you (the application developer) to know nothing about the structure of the database and still develop your application while a dedicated DBA or SQL developer can fine tune the SQL.
- Stored procedures are pre-compiled, so over many repetitions they will be faster, but ONLY if they are called extremely frequently (i.e. a monitoring program)
When all is said and done, its a design decision. Don't take portability into account, you can just have the SQL dev give you the scripts to apply the store procs and run them on installation of the program anyway :)
Hope this helps
