Why does the SqlParamater fail on DBNull values?

  • Thread starter Thread starter Jason
  • Start date Start date
J

Jason

The following code snippet fails if the column contains a DBNull value.

private SqlParameter[] BuildSecurityParamaterArray(
SecurityDS.lac_SecurityRow sec )
{
SqlParameter[] sp = { new SqlParameter("@USER_ID", sec.USER_ID),
new SqlParameter("@USER_TYPE", sec.USER_TYPE) };
}

For example, if sec.USER_TYPE contains a null value, this method throws an
error stating it cannot get the value because it is DBNull, even though null
values are allowed for this column.

Is there some way to make this work?
 
That it accepts nulls is all fine and good except if your data type is
one that does not accept nulls such as double

In that case,

if strAct <> "" then
Cmd.Parameters("@act").Value =System.Convert.ToDouble(strActual)
else
Cmd.Parameters("@actl").Value = DBNull.Value
end if

For instance.

But the other poster is right. Lets see code.
 
I'm guessing sec.USER_TYPE is some kind of intrinsic byval variable (like
integer, double etc.) .. is it?

If it is, 1.1 is inelegant and handling that is kloodgy. In 2.0 you have
generics and you can do Nullable <int> i = null ;

- Sahil Malik
You can reach me thru my blog at
http://www.dotnetjunkies.com/weblog/sahilmalik
 
Sahil Malik said:
I'm guessing sec.USER_TYPE is some kind of intrinsic byval variable (like
integer, double etc.) .. is it?
Click to expand...

Its actually just a string in this instance (there are many more columns in
the table, but I cut it down for the sake of brefity).

The calling code is from an NUnit test harness, with a shortened version of
the form:

[Test]
public void bInsSecurityRec()
{
// SecurityDS is a strongly typed security DataSet containing two
security tables
SecurityDS.lac_SecurityRow sec = ds.lac_Security.Newlac_SecurityRow();

sec.USER_ID = userid;
sec.USER_TYPE = null;

dalc.InsSecurity( sec );
}
 
Back
Top