Question

I observed a strange problem in a piece of code where an adhoc SQL query was not producing the expected output, even though its parameters matched records in the data source. I decided to enter the following test expression into the immediate window:

new SqlParameter("Test", 0).Value

This gave a result of null, which leaves me scratching my head. It seems that the SqlParameter constructor treats zeroes as nulls. The following code produces the correct result:

SqlParameter testParam = new SqlParameter();
testParam.ParameterName = "Test";
testParam.Value = 0;
// subsequent inspection shows that the Value property is still 0

Can anyone explain this behaviour? Is it somehow intentional? If so, it’s potentially rather dangerous…

Answer 1

As stated in the documentation for that constructor:

When you specify an Object in the value parameter, the SqlDbType is inferred from the Microsoft .NET Framework type of the Object.

Use caution when you use this overload of the SqlParameter constructor to specify integer parameter values. Because this overload takes a value of type Object, you must convert the integral value to an Object type when the value is zero, as the following C# example demonstrates.

Parameter = new SqlParameter("@pname", (object)0);

If you do not perform this conversion, the compiler assumes that you are trying to call the SqlParameter (string, SqlDbType) constructor overload.

You simply were calling a different constructor than you thought in your case.

The reason for this is that C# allows an implicit conversion from the integer literal 0 to enum types (which are just integral types underneath), and this implicit conversion causes the (string, SqlDbType) constructor to be a better match for overload resolution than the boxing conversion necessary to convert int to object for the (string, object) constructor.

This will never be a problem when you pass an int variable, even if the value of that variable is 0 (because it is not a zero literal), or any other expression that has the type int. It will also not happen if you explicitly cast the int to object as seen above, because then there is only one matching overload.