Paul Wilson's .NET Blog

Well, since the idea of nullable value types was just plain left out of a modern platform (.NET) in the beginning was incredibly bizarre to me, especially in this age of database interactivity.

Getting nullables to be more integrated is a definitely great start to get the platform (.NET) into CURRENT standards, instead of OO-based C++ standards of 10 years ago (where Objects would serialize/deserialize locally...)

Agreed these "irritations" with the DataReaders is annoying, and IMO the IDataReader interfaces should obviously be extended (via IDataReader2 or IDataReaderEx or something) to provide nullable types through the interface, and hence "encourages" implementing it all the way through to the SqlDataReader's implementation of
"int? IDataReader2.GetInt32(int ordinal)"

Just say no to NULLS!

Join PAN. Programmers Against Nulls!

It's not just IDataReader that's not supported. NONE of the System.Data classes support nullable types. Just try to use something like

command.Parameters.AddWithValue("@SomeParam", (int?)null)

This will throw an exception once you try to execute the command. Yet the following works:

command.Parameters.AddWithValue("@SomeParam", SqlInt32.Null)

There aren't even any implicit/explicit conversions between SqlTypes and Nullable types. I was baffled when I noticed that.

It's things like this that make nullable types *really* annoying to work with when you're doing database work.

Erm, refresh my memory, why were they added again?

Checkbox feature. Let's hope something better shows up in before final release.

Well, one of the major problems is the idea of NULL in the database in the first place.

One of my major complaints about the SQL Server 2000 table design tools is that columns allow NULL by default. This is a pretty significant design decision, and I believe that NULLs should be allowed in the database only in extra-ordinary circumstances.

However, many 'DBAs' allow null by default, and it really creates havoc.

NULLable types are a hack to make programming against screwy database designs easier for client-side programmers.

You know, while you ARE right....

...personally I do not care about the database integration at all. I use an O/R mapper fo rall my database work, including parameters, and I thus can add all the integration and conversion code within MY O/R mapper - so parameters etc. will work.

What really makes me upset is the other part. our points (2) and (3) are in levels that the USER of the O/R mapper has to work with. And there it will come back and hit them. There is no way I can hide (yet again) databinding efficiencies. There is no way I can handle the convert issue.

And this really shows how much an afterthought this is. MS drops the ball again (on databinding). Are they the only company which will take a dozen or so attempts o get this right?

Last year at Teched Europe, someone asked Dan Fernandez about nullable types and datareader... they (he and another MS guy) got that look on their face: "oh erm... whoa, we didn't think of that! we'll pass it on!". Nothing happened apparently.

Oh, btw, DON'T use datareader.IsDBNull(..). It's very slow. Test the value for System.DBNull.Value, much faster. (magnitudes faster)

I also find the lack of integration of nullable types a severe stupidity. I mean, int's and all ARE already structs. All it takes is another field. ONE FIELD.

ok, you can use Nullable<T> but that's almost 50% slower. Why, I don't know, as it's just 1 flag, 1 BIT.

Check out NullableTypes on SourceForge. Works with .NET 1.1 and VB providing useful conversion functions etc.

http://nullabletypes.sourceforge.net

Paul,

Wow, thanks for the headsup.

Wally

WTF?
I thought that interaction with nullable fields in the DB (such as situation #1) was the main line for nullable types in the framework. Mostly to eliminate all kinds of null checking.

If they don't do that then why even spend the time to implement it?


?UsefullType

I think the issue at the core here is that nullable types are never actually nulls.

int? i = null;

Assert(i == null);
Assert((object)i == null); // WILL FAIL

nullable types are simple objects with a flag. I think because all those methods take and return base Object type, when type casted to a nullable type with a "null" value, you wouldn't get a null in result.

I think the problem is not integration, but how the nullable types are implemented in the first place.

That's at least how I understand it.
http://blog.dreamprojections.com/archive/2005/04/10/787.aspx

I don't think anyone expects them to be null -- just to be integrated with their expected uses.

Amen. See also my suggestion on ladybug at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=400bc96d-0faa-4737-ad30-ec088663fddb

I've been reading up on the subject...........And the impedance mismatch continues.

I had an assembly, originally written against .NET 1.1 and now running
on .NET 2.0, that tried to convert...

I use a simple converter for O/R mapping: public static class SqlTypeConverter { public static int? ToNulllableInt32(object o) { SqlInt32 i = (SqlInt32)o; return i.IsNull ? null : (int?)i; } ...or public static int? ToNullable(SqlInt32 i) { return i.IsNull ? null : (int?)i; } ... and so on ... } But, of course, this still doesn't help with the ignorant controls!

Here's how I get around the <null> value in a datareader:

if (myDataReader.GetValue(5).ToString().Length > 0)

{

do stuff

}

ive only used to to test the selected value of a dropdown list when I was populating it from the database and getting the value that had been selected by the user a previous time.

worked like a champ.

the reason I used that if statement was because when I tried to write that value to the page, nothing happened.  So, since testing != null or != "" didnt work, I went with length

Although it's true that the lack of integration is annoying, the fact that I CAN now create a null-value base type is a tremendous relief.  I don't mind using obscure conversion syntax at the border of the data-retrieval-layer if I don't have to pollute the rest of my code with all those ugly SqlTypes.

Le roi est nul!  Vive le roi!

Work-around for NumericUpDown and databinding to dbnull.

Here is the crappy workaround I came up with to handle the fact that Nup controls silently fail on databinding to DBNull.

My scenario is that I have a DataGridView and when the user moves from row to row I display some other information and some of that information is displayed in NumericUpDown controls.

On the WinForm I add a hidden textbox control right under the Nup control and set its DataBindings to be the same as those of the Nup control.

In my SelectionChanged event handler for the dgv, I have check the textbox to see if its nullorEmpty and if so then call the Nup's ResetText and set its Value to be zero, else set its value to be the value in the textbox.

This seems to work.

Sample of my code:

if (string.IsNullOrEmpty(this.TxtLIWage.Text))

{

   this.NupLIWage.Value = 0m;

   this.NupLIWage.ResetText();

}

else

{

   this.NupLIWage.Value = StringToNumber.ConvertToDecimal(this.TxtLIWage.Text);

}

The StringToNumber is my own class that handles converting text to decimal and takes care to culture (Canadian English/French).

This crappy workaround might also come in handy for dealing the DateTimePicker controls too.

Hope this is helpful to others.

Sheir

Pingback from  abusing.me  &raquo; Blog Archive   &raquo; Framework UI - DataBindings und Nullable&lt;T&gt;

Pingback from  Nullable Types in .Net 2.0 &laquo; CollectedDotNet