It's a soup to nuts, everything is on the table, proposition to really get proper protection from SQL Injection.
First, and most important, use the least-priviledge principal when setting up your security. Only the access things MUST have should be allowed for any given login or role. Too much access is the biggest problem.
Next, use stored procedures (as was already mentioned), or, parameterized queries such that you're not building and executing strings of SQL code. Along with this, use the correct data types. If it's a number, use a number, not a string. You need a date or time, use a date or time data type, not a string. In addition, as Eirikur says, validate the input on the code side of things to ensure that dates are dates, etc..
Additionally, SQL Injection requires exploration. There are common errors, make darned sure you're monitoring for them. And, speaking of errors, ensure that you have appropriate error trapping in place such that it's not exposing details of your infrastructure when errors occur, a common approach to understanding if you can be hacked.
Do all this, and you'll be protected. Just some of it isn't enough. I've seen code where it's all in stored procedures, but you're passing giant strings and doing ad hoc query builds instead of parameterized queries. However, it all starts with the right security settings. Just that, and only that, can minimize the harm of a SQL Injection attack if you do nothing else. However, I'd suggest pursuing everything. Defense in depth.