about null values

  • Thread starter Thread starter Tony
  • Start date Start date
T

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
 
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
Click to expand...

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?
 
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 ?
Click to expand...

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?
Click to expand...

DBNull.Value does not have the database format either.

Arne
 
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 ?
Click to expand...

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
 
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 ?
Click to expand...

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?
Click to expand...

DBNull.Value does not have the database format either.
Click to expand...

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.
 
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?
Click to expand...

DBNull.Value does not have the database format either.
Click to expand...

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.
Click to expand...

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

Arne
 
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.
Click to expand...

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.
Click to expand...

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

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-
 
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.
Click to expand...

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

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.
Click to expand...

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
Click to expand...

DBNull is a class. DBNUll.Value is a static field.
- which
means there is a setter subroutine which runs when it is assigned.
Click to expand...

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.
Click to expand...

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.
Click to expand...

This never reaches the database.

Arne
 
<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-
 
Back
Top