Good afternoon!

I have a method that adds a SQL parameter with the right SQLtype based
on a CLR type:

public void AddParam<T>(string name, T value)
{
...
}

I translate 'T' to a valid DbType. The problem is when T is Nullable,
as in

AddParam<int?>(name, x);

How can I get the 'int' from 'int?' inside AddParam() so I can
translate the type & handle NULLs properly?

Things I've tried:

* Nullable.ToObject<T>(value) returns a boxed object.
* value ?? value returns a T?
* Nullable.ValueOrDefault<T>(value) returns a boxed object.
* Try a Nullable-specific AddParam<T>(...) where T : Nullable but that
complains about static structures as a constraint.
* Assign value directly to the SQL procedure but I get a "No mapping
exists from object type System.Nullable to a known managed provider
native type."

Thanks!

-Brian

Why aren't you using a SqlTypes like SqlInt32 instead of « int? » ?

int? has not be introduced with the intent of replacing SqlTypes like
SqlInt32.

S. L.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Good afternoon!
>
> I have a method that adds a SQL parameter with the right SQLtype based
> on a CLR type:
>
> public void AddParam<T>(string name, T value)
> {
> ...
> }
>
> I translate 'T' to a valid DbType. The problem is when T is Nullable,
> as in
>
> AddParam<int?>(name, x);
>
> How can I get the 'int' from 'int?' inside AddParam() so I can
> translate the type & handle NULLs properly?
>
> Things I've tried:
>
> * Nullable.ToObject<T>(value) returns a boxed object.
> * value ?? value returns a T?
> * Nullable.ValueOrDefault<T>(value) returns a boxed object.
> * Try a Nullable-specific AddParam<T>(...) where T : Nullable but that
> complains about static structures as a constraint.
> * Assign value directly to the SQL procedure but I get a "No mapping
> exists from object type System.Nullable to a known managed provider
> native type."
>
> Thanks!
>
> -Brian
>

At some point I have to interface SQL types to 'real' types on business
objects - types clients are familiar with, like int, string, etc. This
is the place I chose to do that.

Thanks for the reply!

Brian,

Probably I'm missing something, but I don't understand what are you trying
to achieve.

Since you're passing a value, you already have type information in it and
you can simply call GetType():

void AddParam(string name, object value)
{
if (value.GetType() == typeof(string))
{
...
}
....
}

If you want to give callers some degree of control over parameter's data
type (like in AddParam("int_column", "123")) then you could add an overload
with datatype parameter:

void AddParam(string name, object value, Type dataType)


HTH,
Alexander

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Good afternoon!
>
> I have a method that adds a SQL parameter with the right SQLtype based
> on a CLR type:
>
> public void AddParam<T>(string name, T value)
> {
> ...
> }
>
> I translate 'T' to a valid DbType. The problem is when T is Nullable,
> as in
>
> AddParam<int?>(name, x);
>
> How can I get the 'int' from 'int?' inside AddParam() so I can
> translate the type & handle NULLs properly?
>
> Things I've tried:
>
> * Nullable.ToObject<T>(value) returns a boxed object.
> * value ?? value returns a T?
> * Nullable.ValueOrDefault<T>(value) returns a boxed object.
> * Try a Nullable-specific AddParam<T>(...) where T : Nullable but that
> complains about static structures as a constraint.
> * Assign value directly to the SQL procedure but I get a "No mapping
> exists from object type System.Nullable to a known managed provider
> native type."
>
> Thanks!
>
> -Brian
>

Alexander Shirshov <(E-Mail Removed)> wrote:
> Probably I'm missing something, but I don't understand what are you trying
> to achieve.
>
> Since you're passing a value, you already have type information in it and
> you can simply call GetType():
>
> void AddParam(string name, object value)
> {
> if (value.GetType() == typeof(string))
> {
> ...
> }
> ....
> }

Note that that's a lot slower (and less readable, IMO) than:

if (value is string)

or

string valAsString = value as string;
if (valAsString != null)
{
....
}

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Note that that's a lot slower (and less readable, IMO) than:
>
> if (value is string)

Is uniformity important for readability? "is" will not work for value types.

And I don't think the performance is an issue for the original poster. DB
operations are many orders of magnitude slower and I don't think anyone
would be adding query parameters by thousands.

"Alexander Shirshov" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> "Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Note that that's a lot slower (and less readable, IMO) than:
>>
>> if (value is string)
>
> Is uniformity important for readability? "is" will not work for value
> types.
>

I believe you are mistaken. "as" will not work for value types, but is will
work perfectly well. "is" will(atleast in the 2.0 beta) issue a warning
informing you that the expression will always be true if you apply is to a
value type variable(ie meaning a non-boxed value type), but it still works.

You're probably right. I was trying to use generics to avoid boxing and
a dozen type-specific methods that are all pretty much the same. But
since It's assigned to SqlParameter.Value we box anyway.

The other problem is even if value is an int?, for example, 'if (value
is Nullable)' returns false, so it's not easy to figure that out in a
generic <T> way.

Thanks for the input!

-Brian

Yes, I quoted and commented not the sentence I intended. Thanks for
correcting.

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:(E-Mail Removed)...
>
> "Alexander Shirshov" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>>
>> "Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Note that that's a lot slower (and less readable, IMO) than:
>>>
>>> if (value is string)
>>
>> Is uniformity important for readability? "is" will not work for value
>> types.
>>
>
> I believe you are mistaken. "as" will not work for value types, but is
> will work perfectly well. "is" will(atleast in the 2.0 beta) issue a
> warning informing you that the expression will always be true if you apply
> is to a value type variable(ie meaning a non-boxed value type), but it
> still works.
>
>