>Hi Mike,
>
>I understand that. The question is - how to prevent the incorrect input using parameterized queries.

With parameterized Ad-Hoc SQL you don't need to do anything to prevent SQL Injection Attacks. However, if you don't want your table to have "select * from table" etc. then you would have to do something. At least that won't be executed which is the real danger.

>We're installing URLScan, but how would you do this in code? Say, in Stored procedure do you need to analyze each parameter?

That would be a horrible burden on the server. However, even if you're building dynamic SQL in your stored procedures, as long as you parameterize, you will not have a hacker running his SQL on your server and you will not have to add code to analyze each parameter.

>Or should you try to do this in the front-end?

Front end if possible. An army of CPUs is more powerful than one.

> Or use triggers in tables rejecting some input?

Triggers are also a burden on the server.

>
>>There are two kinds of injection attacks. One is SQL Injection, which is when the user enters SQL code which you the programmer concatenate and turn into one big SQL command. This is prevented by parameterizing what the user enters. This also requires NO cleaning up of the user's entries.
>>
>>Instead of
>>
>>m.lcCmd = "select * from table where field = " + thisform.userentry
>>
>>do
>>
>>m.lcUserEntry = thisform.userentry
>>m.lcCmd = "select * from table where field = ?m.lcUserEntry"
>>
>>The other injection is HTML / Javascript being entered into the fields. These you do have to try and filter out.
>>