about null values

[Tony]

Hello!

Here I have a code snippet. I read a book and the book says the following.
"When you want to set the value of a column to a null value, don't use the
Null keyword from you programming language. The .NET framework includes a
class in the System.namespace called DBNull. To set the value of a column in
a DataRow to a null value use the value property of the DBNull class as
shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C# instead of
the DBNull class ?

//Tony

 

[Rick Lones]

Hello!

Here I have a code snippet. I read a book and the book says the following.
"When you want to set the value of a column to a null value, don't use the Null
keyword from you programming language. The .NET framework includes a class in
the System.namespace called DBNull. To set the value of a column in a DataRow to
a null value use the value property of the DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C# instead of the
DBNull class ?

//Tony

Because they do not necessarily produce the same encoding result in the database?

Encodings in general are arbitrary, there is no reason at all that "null" as
encoded by the .Net runtime will look anything like the placeholder used by any
given DBMS to mark a null database field. And this would still be true even if
all .Net types actually allowed a null value.

They are explicitly telling you, "Encode it this way if you expect the DBMS to
process it correctly". How much more do you really need to know?

 

[Arne Vajhøj]

Here I have a code snippet. I read a book and the book says the
following.
"When you want to set the value of a column to a null value, don't use
the Null
keyword from you programming language. The .NET framework includes a
class in
the System.namespace called DBNull. To set the value of a column in a
DataRow to
a null value use the value property of the DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C#
instead of the
DBNull class ?

Because they do not necessarily produce the same encoding result in the
database?

Encodings in general are arbitrary, there is no reason at all that
"null" as encoded by the .Net runtime will look anything like the
placeholder used by any given DBMS to mark a null database field. And
this would still be true even if all .Net types actually allowed a null
value.

They are explicitly telling you, "Encode it this way if you expect the
DBMS to process it correctly". How much more do you really need to know?

DBNull.Value does not have the database format either.

Arne

 

[Arne Vajhøj]

Here I have a code snippet. I read a book and the book says the following.
"When you want to set the value of a column to a null value, don't use
the Null keyword from you programming language. The .NET framework
includes a class in the System.namespace called DBNull. To set the value
of a column in a DataRow to a null value use the value property of the
DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C# instead
of the DBNull class ?

I guess that it is a lot about tradition. A database NULL is
something special.

But there are at least one place in the .NET API where it can
make a practical difference.

ExecuteScalar returns DBNull if it finds a row but the column
is NULL but null if it does not find a row at all.

You may also want to read Fowler PEAA "special case pattern"
for some arguments for this construct.

Arne

 

[Rick Lones]

Here I have a code snippet. I read a book and the book says the
following.
"When you want to set the value of a column to a null value, don't use
the Null
keyword from you programming language. The .NET framework includes a
class in
the System.namespace called DBNull. To set the value of a column in a
DataRow to
a null value use the value property of the DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C#
instead of the
DBNull class ?

Because they do not necessarily produce the same encoding result in the
database?

Encodings in general are arbitrary, there is no reason at all that
"null" as encoded by the .Net runtime will look anything like the
placeholder used by any given DBMS to mark a null database field. And
this would still be true even if all .Net types actually allowed a null
value.

They are explicitly telling you, "Encode it this way if you expect the
DBMS to process it correctly". How much more do you really need to know?

DBNull.Value does not have the database format either.

Sure, why should it? There are many different DBMS packages and no particular
reason for them all to encode their null fields the same way. That's why a
special marker for null values is needed, I would think.

 

[Arne Vajhøj]

On 12/13/2011 8:56 AM, Tony wrote:
Here I have a code snippet. I read a book and the book says the
following.
"When you want to set the value of a column to a null value, don't use
the Null
keyword from you programming language. The .NET framework includes a
class in
the System.namespace called DBNull. To set the value of a column in a
DataRow to
a null value use the value property of the DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C#
instead of the
DBNull class ?

Because they do not necessarily produce the same encoding result in the
database?

Encodings in general are arbitrary, there is no reason at all that
"null" as encoded by the .Net runtime will look anything like the
placeholder used by any given DBMS to mark a null database field. And
this would still be true even if all .Net types actually allowed a null
value.

They are explicitly telling you, "Encode it this way if you expect the
DBMS to process it correctly". How much more do you really need to know?

DBNull.Value does not have the database format either.

Sure, why should it? There are many different DBMS packages and no
particular reason for them all to encode their null fields the same way.
That's why a special marker for null values is needed, I would think.

But it does not explain why DBNull.Value is used as that marker and
not null.

Arne

 

[Rick Lones]

On 12/13/2011 9:29 AM, Rick Lones wrote:
On 12/13/2011 8:56 AM, Tony wrote:
Here I have a code snippet. I read a book and the book says the
following.
"When you want to set the value of a column to a null value, don't use
the Null
keyword from you programming language. The .NET framework includes a
class in
the System.namespace called DBNull. To set the value of a column in a
DataRow to
a null value use the value property of the DBNull class as shown here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C#
instead of the
DBNull class ?

Because they do not necessarily produce the same encoding result in the
database?

Encodings in general are arbitrary, there is no reason at all that
"null" as encoded by the .Net runtime will look anything like the
placeholder used by any given DBMS to mark a null database field. And
this would still be true even if all .Net types actually allowed a null
value.

They are explicitly telling you, "Encode it this way if you expect the
DBMS to process it correctly". How much more do you really need to know?

DBNull.Value does not have the database format either.

Sure, why should it? There are many different DBMS packages and no
particular reason for them all to encode their null fields the same way.
That's why a special marker for null values is needed, I would think.

But it does not explain why DBNull.Value is used as that marker and
not null.

I see what you mean (I think). Yet it somehow seems quite plausible to me that
a special way of specifying a null database field in particular (as opposed to a
general null reference) could possibly have advantages or avoid ambiguities.

Actually we are not talking so much here about the DBMS itself as with how the
..Net runtime interfaces with any given DBMS engine, I think. Syntactically,
"null" is just a value but DB.Null is a property - which means there is a setter
subroutine which runs when it is assigned. That subroutine is a black box which
may be jumping through all kinds of complex hoops to make sure that the null
field value appropriate to the particular DBMS at hand is being encoded properly.

I am not a DBMS or .Net runtime architect, just a sometimes user of them and I
certainly don't mean to claim I know the details of what is going on under the
covers of .Net or how the design decisions got made. But I was involved with
the underlying file system support for a DBMS long ago and so I do know that
quite a lot goes on to make sure that everything comes out right in the physical
database even though the details are normally of no real relevance or interest
to the user.

-rick-

 

[Arne Vajhøj]

On 12/17/2011 10:24 PM, Arne Vajhøj wrote:
On 12/13/2011 9:29 AM, Rick Lones wrote:
On 12/13/2011 8:56 AM, Tony wrote:
Here I have a code snippet. I read a book and the book says the
following.
"When you want to set the value of a column to a null value, don't
use
the Null
keyword from you programming language. The .NET framework includes a
class in
the System.namespace called DBNull. To set the value of a column in a
DataRow to
a null value use the value property of the DBNull class as shown
here."

DataRow row = tbl.Rows.Find("Test");
row["CompanyName"] =DBNull.Value;

Now what could the reason be not to use the null keyword from C#
instead of the
DBNull class ?

Because they do not necessarily produce the same encoding result in
the
database?

Encodings in general are arbitrary, there is no reason at all that
"null" as encoded by the .Net runtime will look anything like the
placeholder used by any given DBMS to mark a null database field. And
this would still be true even if all .Net types actually allowed a
null
value.

They are explicitly telling you, "Encode it this way if you expect the
DBMS to process it correctly". How much more do you really need to
know?

DBNull.Value does not have the database format either.

Sure, why should it? There are many different DBMS packages and no
particular reason for them all to encode their null fields the same way.
That's why a special marker for null values is needed, I would think.

But it does not explain why DBNull.Value is used as that marker and
not null.

I see what you mean (I think). Yet it somehow seems quite plausible to
me that a special way of specifying a null database field in particular
(as opposed to a general null reference) could possibly have advantages
or avoid ambiguities.

It is necessary for ExecuteScalar return value.

But that has nothing to do with database internal format.

Actually we are not talking so much here about the DBMS itself as with
how the .Net runtime interfaces with any given DBMS engine, I think.
Syntactically, "null" is just a value but DB.Null is a property

DBNull is a class. DBNUll.Value is a static field.

- which
means there is a setter subroutine which runs when it is assigned.

There are no setter.

That
subroutine is a black box which may be jumping through all kinds of
complex hoops to make sure that the null field value appropriate to the
particular DBMS at hand is being encoded properly.

It is a marker so all the formatting are done outside the class.

I am not a DBMS or .Net runtime architect, just a sometimes user of them
and I certainly don't mean to claim I know the details of what is going
on under the covers of .Net or how the design decisions got made. But I
was involved with the underlying file system support for a DBMS long ago
and so I do know that quite a lot goes on to make sure that everything
comes out right in the physical database even though the details are
normally of no real relevance or interest to the user.

This never reaches the database.

Arne

 

[Rick Lones]

<Reposting, not sure why it didn't make it in last night>

Ha! Wrong on all counts then. Thank you for that. (Hardly the first time,
though.)

Merry Christmas,
-rick-