working with SQL null values....

  • Thread starter Thread starter Aussie Rules
  • Start date Start date
A

Aussie Rules

Hi,
I have a result set that sometimes will contain a Null value from the SQL
server.

I have looked into this and am trying to manage this with the following

If Not DBNull.Value.Equals(dRow("path")) Then
advCell.Text = dRow("path")
Else
advCell.Text = "No Path"
End If


However it doesn't matter what the result set contains.. it also execute top
condition..

Am I doing something wrong.... is there a better way to deal with Sql Null
values ?
 
DBNulls are so frustrating to me that I cheat and make all my columns
non-nullable. I then just have a default value that means "Null" e.g. "" for
a nvarchar column, VB's "New Date" for a Date field etc.

Not pretty, but it saves a lot of DBNull checking code. And the difference
between DBNull and "" is not as big as you would think.
 
SurturZ said:
DBNulls are so frustrating to me that I cheat and make all my columns
non-nullable. I then just have a default value that means "Null" e.g. ""
for
a nvarchar column, VB's "New Date" for a Date field etc.

Not pretty, but it saves a lot of DBNull checking code. And the difference
between DBNull and "" is not as big as you would think.

Don't want to start a war but I have to disagree. The difference between
null and "" is that null means that the database does not know the value and
"" is the value (a string with zero length). While what you are doing may
work in some cases concider the case of an apartment number. Null means you
don't know if there is an apartment number but "" means there is no
apartment number.

LS
 
Lloyd Sheen said:
Don't want to start a war but I have to disagree. The difference
between null and "" is that null means that the database does not
know the value and "" is the value (a string with zero length). While what
you are doing may work in some cases concider the case of
an apartment number. Null means you don't know if there is an
apartment number but "" means there is no apartment number.


I agree with both of you. In some cases you have to distinguish between Null
and "", in some cases you don't have to. In my personal experience, the
former happens much more often, therefore I handle those like David does.


Armin
 
Armin Zingler said:
I agree with both of you. In some cases you have to distinguish between
Null
and "", in some cases you don't have to. In my personal experience, the
former happens much more often, therefore I handle those like David does.


Armin

Again I would state that if you can handle the data in any way but it should
be stored in the database as nulls to indicate that state. There are plenty
of methods to display the data after including COALESCE in SQL and Iff in
VB.NET

LS
 
Don't want to start a war but I have to disagree. The difference between
null and "" is that null means that the database does not know the value and
"" is the value (a string with zero length). While what you are doing may
work in some cases concider the case of an apartment number. Null means you
don't know if there is an apartment number but "" means there is no
apartment number.

Oh, I agree with you. Setting database fields to not nullable is a cheat.

However, I have found that the "hacks" to avoid DBNulls are usually easier
to read than processing DBNulls. Let's face it, programmers that allow
DBNulls in their database usually have some little function called NULLSAFE
or something that converts DBNulls to empty strings anyway.

For your example of apartment number, either the address is complete or it
isn't. If the apartment number is "" you can assume the address is not an
apartment and format the address appropriately.

In my experience, end users rarely distinguish between "not known" and
"doesn't exist". YMMV of course.
 
Null Date

Fair enough, I use "01/01/1753 12:00:00" (oldest possible date), which I
then convert to a New Date.

One place you really can't get away from DBNull is for fields that are part
of a relation. e.g. if you have a link to the Employer table from your Client
table, but some Clients are unemployed.
 
Back
Top