Scribd
Upload
12 views1 page

Use Type

Uploaded by

Vk Tech
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views1 page

Use Type

Uploaded by

Vk Tech
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

Use type-safe SQL parameters

The Parameters collection in the Database Engine provides type checking and length validation. If you
use the Parameters collection, input is treated as a literal value instead of as executable code. Another
benefit of using the Parameters collection is that you can enforce type and length checks. Values outside
the range trigger an exception. The following code fragment shows using the Parameters collection:

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);

myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;

SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",

SqlDbType.VarChar, 11);

parm.Value = Login.Text;

In this example, the @au_id parameter is treated as a literal value instead of as executable code. This
value is checked for type and length. If the value of @au_id doesn't comply with the specified type and
length constraints, an exception is thrown.

Use parameterized input with stored procedures

Stored procedures might be susceptible to SQL injection if they use unfiltered input. For example, the
following code is vulnerable:

SqlDataAdapter myCommand =

new SqlDataAdapter("LoginStoredProcedure '" + Login.Text + "'", conn);

If you use stored procedures, you should use parameters as their input.

You might also like