Nullable Types

[Steven Livingstone]

I've just blogged some stuff on Nullable types in net 2.0.
http://stevenr2.blogspot.com/2006/01...oalescing.html

Question however as to why you can't simply get an implcit conversion from a
..Net value type to to a Sql Server data type rather than having to use null
cheked and DBNull.Value ?

Does anyone have some explanation as to why this is so tricky as to be
included?

http://stevenR2.com

[Steven Livingstone]

of course i meant - as not to be included... :)

"Steven Livingstone" <co*****@NOSPAM .stevenR2.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I've just blogged some stuff on Nullable types in net 2.0.
http://stevenr2.blogspot.com/2006/01...oalescing.html

Question however as to why you can't simply get an implcit conversion from
a .Net value type to to a Sql Server data type rather than having to use
null cheked and DBNull.Value ?

Does anyone have some explanation as to why this is so tricky as to be
included?

http://stevenR2.com

[Steven Livingstone]

FWIW, there was a discussion a while back where this was considered (at
least a part of VB and you'd have to assume C#).

http://blogs.msdn.com/vbteam/archive...13.aspx#159656

Seems MS considered it. So either i'm missing something and it's already
done, or they chose not to do it.

steven :: http://stevenR2.com
"Steven Livingstone" <co*****@NOSPAM .stevenR2.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I've just blogged some stuff on Nullable types in net 2.0.
http://stevenr2.blogspot.com/2006/01...oalescing.html

Question however as to why you can't simply get an implcit conversion from
a .Net value type to to a Sql Server data type rather than having to use
null cheked and DBNull.Value ?

Does anyone have some explanation as to why this is so tricky as to be
included?

http://stevenR2.com

[Nicholas Paldino [.NET/C# MVP]]

Steven,

It's not tricky, really. The SQL nullable types were meant as a very
specific solution to a particular domain space. Nullable types are extended
to a much larger space.

Also, I believe that nullable types are meant to be a replacement, not
an interop mechanism.

I don't know that this necessarily justifies it, though.

If anything, I think that the SQL nullables will just go away (meaning,
they will be left in there for backwards compatability), now that a general
solution is in place.

Hope this helps.
"Steven Livingstone" <co*****@NOSPAM .stevenR2.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I've just blogged some stuff on Nullable types in net 2.0.
http://stevenr2.blogspot.com/2006/01...oalescing.html

Question however as to why you can't simply get an implcit conversion from
a .Net value type to to a Sql Server data type rather than having to use
null cheked and DBNull.Value ?

Does anyone have some explanation as to why this is so tricky as to be
included?

http://stevenR2.com

[Randal]

>>Does anyone have some explanation as to why this is so tricky as to be

included?

Will it ever be? In SQL Server NULL is a value type while null in C# is
an uninitialized object. So if I wanted to say this:

xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"] = null

Then I am setting that object to null, and not assigning the SQL server
column to the SQL value of NULL. The same goes with passing in a C#
null parameter to a stored proc. C# thinks I am passing in nothing (an
unintialized object) when what I really want to pass in is the SQL
value type of NULL.

_Randal

[Steven Livingstone]

Well the reason nullable value types were brought out were (in part) because
in C# it isn't always an unitialized *object* you may be passing - i can now
nullify an int? rather than the workarounds of yesteryear. This was created
in part to get round such problems.
But, in setting the value of a stored procedure parameter to NULL (or null
in c#) i think in almost every case you will do a check for null and then
set it to DBNull.Value - if you have exception cases i'd like to hear them.
It just means that i have to check for everything i do.

In your case

xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"] = null

this may set the object to null, but if i did (not saying i can, but if)

xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"].Value = null

then it would indicate to me that the actual value of the CurrentSalary was
set to null.

In the latter case, it is fairly trivial to then just use DBNull
implicitly - i'd have figured.

But i understand what you are saying and that makes sense also.

steven :: http://stevenR2.com

"Randal" <fr******@swbel l.net> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

Does anyone have some explanation as to why this is so tricky as to be
included?

Will it ever be? In SQL Server NULL is a value type while null in C# is
an uninitialized object. So if I wanted to say this:

xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"] = null

Then I am setting that object to null, and not assigning the SQL server
column to the SQL value of NULL. The same goes with passing in a C#
null parameter to a stored proc. C# thinks I am passing in nothing (an
unintialized object) when what I really want to pass in is the SQL
value type of NULL.

_Randal

[Steven Livingstone]

Thanks Nicholas - i'd expect them to go too.

I've not read up too much on CLR data types in SQL Server 2005, but it would
have been nice for the C# null to just flow from code to data where maybe a
CLR null was the default NULL in your table columns (even it is were
configurable on install). Hell this would be nice to all the CLR datatypes
that can be supported in sql (int, shorts, strings and so on) - but i guess
going from nvarchar(50) to string requires some fundamenal changes and i'm
just dreaming :) Give me 5 mins and i'll have SQL 2005 being an OO database!

There may well be perfectly good reasons why this is not the case and i'm
never too old to be told why?!

Thanks for the help,
steven :: http://stevenR2.com
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c om> wrote in
message news:ut******** ******@TK2MSFTN GP15.phx.gbl...

Steven,

It's not tricky, really. The SQL nullable types were meant as a very
specific solution to a particular domain space. Nullable types are
extended to a much larger space.

Also, I believe that nullable types are meant to be a replacement, not
an interop mechanism.

I don't know that this necessarily justifies it, though.

If anything, I think that the SQL nullables will just go away (meaning,
they will be left in there for backwards compatability), now that a
general solution is in place.

Hope this helps.
"Steven Livingstone" <co*****@NOSPAM .stevenR2.com> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

I've just blogged some stuff on Nullable types in net 2.0.
http://stevenr2.blogspot.com/2006/01...oalescing.html

Question however as to why you can't simply get an implcit conversion
from a .Net value type to to a Sql Server data type rather than having to
use null cheked and DBNull.Value ?

Does anyone have some explanation as to why this is so tricky as to be
included?

http://stevenR2.com

[Scottie_do]

Getting into the guts of it, is it true that nullable types is a struct of an
Int that lives on the stack and has an extra field that says "I'm NULL"?
Anyone have anymore insight on the implementation?

Not sure if this helps but I hear that matching DB types with intrinsic
types is something the C# language team is working on (Whoohoo!) - See below

http://msdn.microsoft.com/msdntv/epi...h/manifest.xml

Sorry I can't offer the correct syntax for you to use in your program. I
would want to do the same thing.
"Randal" wrote:

Does anyone have some explanation as to why this is so tricky as to be
included?

Will it ever be? In SQL Server NULL is a value type while null in C# is
an uninitialized object. So if I wanted to say this:

xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"] = null

Then I am setting that object to null, and not assigning the SQL server
column to the SQL value of NULL. The same goes with passing in a C#
null parameter to a stored proc. C# thinks I am passing in nothing (an
unintialized object) when what I really want to pass in is the SQL
value type of NULL.

_Randal

[William Stacey [MVP]]

If you ask me, all this null stuff is confusing as heck. I got along just
find with no null value types. First thing Jim Gray does on all his tables
is not allow nulls. Now we also have "IsNull" and "Is Null" to worry about
on CLR UDTs and nullable value types in c#, and Uggg. I would like the old
days (~last year) with value types and ref types and ref types can be null
and get rid of null value types on SQL all together (right, that will
happen).

--
William Stacey [MVP]

"Scottie_do " <Sc*******@disc ussions.microso ft.com> wrote in message
news:29******** *************** ***********@mic rosoft.com...
| Getting into the guts of it, is it true that nullable types is a struct of
an
| Int that lives on the stack and has an extra field that says "I'm NULL"?
| Anyone have anymore insight on the implementation?
|
| Not sure if this helps but I hear that matching DB types with intrinsic
| types is something the C# language team is working on (Whoohoo!) - See
below
|
|
http://msdn.microsoft.com/msdntv/epi...h/manifest.xml
|
| Sorry I can't offer the correct syntax for you to use in your program. I
| would want to do the same thing.
|
|
| "Randal" wrote:
|
| > >>Does anyone have some explanation as to why this is so tricky as to be
| > >>included?
| >
| > Will it ever be? In SQL Server NULL is a value type while null in C# is
| > an uninitialized object. So if I wanted to say this:
| >
| > xmlDataSet.Tabl es[0].Rows[0]["CurrentSal ary"] = null
| >
| > Then I am setting that object to null, and not assigning the SQL server
| > column to the SQL value of NULL. The same goes with passing in a C#
| > null parameter to a stored proc. C# thinks I am passing in nothing (an
| > unintialized object) when what I really want to pass in is the SQL
| > value type of NULL.
| >
| > _Randal
| >
| >

[Jon Skeet [C# MVP]]

William Stacey [MVP] <wi************ @gmail.com> wrote:

If you ask me, all this null stuff is confusing as heck. I got along just
find with no null value types. First thing Jim Gray does on all his tables
is not allow nulls. Now we also have "IsNull" and "Is Null" to worry about
on CLR UDTs and nullable value types in c#, and Uggg. I would like the old
days (~last year) with value types and ref types and ref types can be null
and get rid of null value types on SQL all together (right, that will
happen).

I'm perfectly happy with nullable types - but we're missing one part of
the quadrant, which is to be able to declare reference type variables
which can *never* be null:

string! x = "hello"; // Fine
string! x = null; // Compiler complains

(Just as an example.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too