I'm also struggling with this...

>I have a question about this Keith ... what are you doing with the data once you're done with it on the UI side ... AFAIK, you can't send Nothing (or null in C#) back to the Database. Actually, I've discovered that you can't send DBNull back to the Database either (at least not SQL Server), but that's another story. <g>

Really? I didn't know that. There's gotta be some way to do this though - maybe a method on the Row?

>I don't really see a good reason to cast DBNull to Nothing though ... what does that give you? You still need to test for Nothing, don't you? DBNull and Nothing mean different things, one is a NULL value in a database column, the other means basically that an object hasn't been instantiated ... so, I'm just curious about how you're utilizing this. Maybe I'm missing something useful. <g>

If you pass the value that you got from the database to other methods those methods likely check for null in strings etc. but they are not likely to check for DbNull... The thing too is that dbNull only works on an object type - once you assign or cast this value to something else that null is gone (usually with a failure). This is an issue if you pass data into methods by parameter for validation/conversion or whatever generic feature...

Case in point: What do you do with a strongly typed DataRow value? You have to check for null before you use it. And when databinding? These scenarios drive me crazy <g>...

The biggest issue as I see it is that most value types don't support null. Neither do the controls that can use them so you always end up with a scenario were dbNull or null in general is an outcast. this is relatively easy to fix if you have custom controls for everything, but still imperfect as it's a specific implementation that has to make some assumptions on what null means.

I personally - if I have a choice - don't use nulls in the database or use it only on fields that absolutely require it which tends to be very few. Of course, one doesn't get to always choose... instead I use defaults on everything possible. The other problem here is that .Net automatically sets everything to NULL which in turn causes problems when updating the database if you don't have nulls enabled. You may remember this discussion we had a while back about this issue - my workaround for that one is to pre-generate DataRow values with 'empty' values overwriting the default NULL whenever a new record is generated.

Null support with ADO.Net is horrible IMHO unless you truly do everythign manual.

+++ Rick ---


>
>I wrote a function that returns a specified default if you pass it a DBNull, so I can say
>GetNonNull(row["MyColumn"], "") and it will return whatever's in MyColumn unless it's DBNull and then it will return "". The function is overloaded so that if the datatype I pass it is numeric, I can return a zero, or if I pass a date column, it can return a specified date, etc.
>
>~~Bonnie
>
>>I have another one:
>>
>>.NET does not automatically cast DBNull to Nothing, so I wrote a nvl() function that flip-flops between DBNull and Nothing. Now my code is full of calls to this function!
>>
>>There might be a valid reason why .NET does not do this, but I have yet to come across a scenario where I could see that it would be a problem.