Datarow and dbNull

[Mr. X.]

DataRow returns an object.
In vb I can check whether the object has value of dbNull.
In C# the solution I make is :
object f;
....
if f.Equals(DBNull.Value) ...

Is there any function like IsDBNull in C# ?

Thanks

 

[Jeff Johnson]

DataRow returns an object.
In vb I can check whether the object has value of dbNull.
In C# the solution I make is :
object f;
...
if f.Equals(DBNull.Value) ...

Is there any function like IsDBNull in C# ?

The DataReader class has the IsDBNull() method. The DataRow class has an
IsNull() method.

By the way, this is not a "function in C#." It is a function on a class in
the .NET Framework. You need to learn to separate the C# language from the
Base Class Library. VB.NET can use these methods the same way that C#,
managed C++, COBOL.NET, or any other .NET language can.

Coming from VB the main thing you need to do is to remove the training
wheels that were almost forced on you (unfortunately often by Microsoft's
own examples). And before you think I'm some VB basher, please note that
I've worked with VB far longer than C#, and I'm quite a fan of classic VB. I
just don't like what it became in .NET. It had a chance to grow up and it
didn't.

 

[Arne Vajhøj]

Coming from VB the main thing you need to do is to remove the training
wheels that were almost forced on you (unfortunately often by Microsoft's
own examples). And before you think I'm some VB basher, please note that
I've worked with VB far longer than C#, and I'm quite a fan of classic VB. I
just don't like what it became in .NET. It had a chance to grow up and it
didn't.

Given that VB.NET and C# are almost machine convertible, then
I would say that VB.NET is as grown up as C# regarding full
OOP etc..

Is the reason for you considering not grown up, that they did not
remove all those VBold'isms? If they had that, then they could
probably just as well had dumped the language entirely - VB.NET's
main justification must be the compatibility with VBold.

(actually that compatibility is not even that good, but
in a few areas it is there)

Arne

 

[Arne Vajhøj]

DataRow returns an object.
In vb I can check whether the object has value of dbNull.
In C# the solution I make is :
object f;
...
if f.Equals(DBNull.Value) ...

Is there any function like IsDBNull in C# ?

o.Equals(DBNull.Value)
o == DBNull.Value
o is DBNull

should all work fine. Take your pick.

And as Jeff mentioned various classes has IsDBNull
methods.

Arne

 

[Jeff Johnson]

Given that VB.NET and C# are almost machine convertible, then
I would say that VB.NET is as grown up as C# regarding full
OOP etc..

Is the reason for you considering not grown up, that they did not
remove all those VBold'isms? If they had that, then they could
probably just as well had dumped the language entirely - VB.NET's
main justification must be the compatibility with VBold.

Mainly it's Microsoft's attitude toward the language. At one of the MVP
summits I went to they were asking for some people to contribute to MSDN
documentation for VB, mainly in code examples. But they wanted to be sure
the examples were done "The VB way." That meant using, for example, MsgBox()
as opposed to MessageBox(). In other words, they were going out of their way
to avoid using the Framework directly and using the VB-happy-smiley-face
methods as much as possible. This sort of thing puts VB users at a huge
disadvantage if they change languages, because they've been shielded from
the Framework as much as possible and now have TWO things to learn: a new
language AND the use of the Framework. A C# person thrust into VB would only
have the language to contend with.

Yes, VB CAN be used in a "grown-up" way, but unfortunately many people
aren't learning to use it that way. I don't even have a problem with the
Microsoft.VisualBasic namespace per se; it's the fact that even new VB users
are still relying on it heavily that bothers me.

 

[Arne Vajhøj]

Mainly it's Microsoft's attitude toward the language. At one of the MVP
summits I went to they were asking for some people to contribute to MSDN
documentation for VB, mainly in code examples. But they wanted to be sure
the examples were done "The VB way." That meant using, for example, MsgBox()
as opposed to MessageBox(). In other words, they were going out of their way
to avoid using the Framework directly and using the VB-happy-smiley-face
methods as much as possible. This sort of thing puts VB users at a huge
disadvantage if they change languages, because they've been shielded from
the Framework as much as possible and now have TWO things to learn: a new
language AND the use of the Framework. A C# person thrust into VB would only
have the language to contend with.

Yes, VB CAN be used in a "grown-up" way, but unfortunately many people
aren't learning to use it that way. I don't even have a problem with the
Microsoft.VisualBasic namespace per se; it's the fact that even new VB users
are still relying on it heavily that bothers me.

I agree with all of that.

I guess it is really the inheritance from "Mort"!

Arne