It is very common to us from CSS Security receive calls about SQL Injection and sometimes customers prefers to apply a bandage in the perimeter rather than work in the real root cause. When I say beyond the perimeter is because as a matter of fact, the internal user will still be able to exploit this vulnerability if the security administrator just put a bandage in the perimeter. I understand that many times they don't have enough resources to fix the applications, but it is very important to set the correct expectation about where the real root cause is located. By trying to fix the issue in the perimeter you are lowering the risk, but the real vulnerability is still there. In the perimeter ISA Server can help with some built in capabilities in the HTTP filter (by manually adding signatures), but the process is still manual and hard to mitigate all the possibilities.
Neil Carpenter from CSS Security IR (Incident Response) Team put together a list of amazing info about how it works, how to prevent this in the source and some samples about that. Check this list here:
MSRC’s advisory, includes links to tools for developers and IT professionals
Covers the ins-and-outs of the mass SQL attacks
Covers how to use parameterized queries in classic ASP
Additional examples of parameterized queries