- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
you should declare sql descriptor area, alloc memory for every data type in prepared statement and only then access data
Admin
I love the way that it's written in upspeak?
Admin
Correction: "foo as type" does not perform any conversion. It just checks if the variable is of the expected type; if not, it returns null. (With numeric types it is necessary to perform casting, because there's no guarantee about what type the database actually returns. For example, in MS SQL server the database may serve numeric fields as the appropriate .NET types, but in Oracle the same table may serve them as System.Decimal.) That said, you should have used something like Linq to database to shield yourself from such differences.
Admin
Ouch... To be fair,
(Int32)dr["CustNum"]
won't work if the column is nullable, so if this was written before nullable types were introduced, one still needs that DBNull.Value comparison. But not the rest of what they did.Admin
As ugly as this is, the 'as' operator has been part of C# for decades. It doesn't work for value types (int, double, bool, etcetera) because a null value is not valid for those types. Strings however are stored as reference types and have a null value, so the 'as' operator works anyway. Not very consistent, I know. TRWTF though is that Convert.ToBoolean("0") and Convert.ToBoolean("1") do not evaluate to false and true, but instead throw. So if you use a BIT data type on Sql Server with values 0 and 1, this code breaks.
Admin
Imagine if bakers worked like this? Take flour, bake it to make bread, then use a sophisticated chemical process to break it back down into flour and water. Then use the resulting flour for something else.
Admin
Why are you handling order identifiers as integers? Do you ever need to perform an arithmetic operation on one?
Admin
Since it sounds like it flew over some heads, the comparison against DBNull is there because DBNull.ToString() returns "" instead of null. In a database where there's a difference between "" and null, a simple string cast or conversion doesn't cut it.
Admin
// i had to deal with SqlDataReader too recently. DBNull is a pain. i agree that it could be shorter (repeating the field names is also error prone). i solved it differently though. i simply created a function that converts an object from DBNull to null or leaves it the same if it isn't DBNull. i find that this more immediately addresses the problem:
object UnDBNull(object x) { return (Convert.IsDBNull(x) ? null : x); }
(string)UnDBNull(dr["Cust_Address"])
// your solution is a bit shorter but i'm worried about silent failures if you get the type wrong when null is an acceptable value: dr["Cust_Address"] as string
Admin
Isn't that exactly what your body does when you eat said cake?
Admin
My favorite part is after he knows that value is null his return of “typed” null.
Admin
The 'as' operator isn't new. In fact, it's been a part of the language since 1.0.
Remy: I was checking the docs and misread that
is
was introduced in C# 7.0, and thought it wasas
.Admin
That's one of the arguments against Intelligent Design.
I guess this code is also an argument against it.
Admin
Isn't
obj as MyType
, like, old as C#?(or at least, old as C# 2.0 (circa Visual Studio 2005), which also supported nullable types)
Admin
Well, they're one step ahead of our old* code, where we pass DataSets around, and hope the type/name/etc of any returned data never changes. Sigh.
Working on bringing this place into the late 20th century...
*Newer code not quite as bad.
Admin
To the best of my recollection, I have never pooped flour.
Admin
is is old too, I think it's as old as as.
Beginning with C# 7.0 you can use it in a switch statement.
Admin
The "typed" nulls are required, at least for the bool? and int? fields, as both branches of the ternary operator have to be of the same type, and null cannot be converted to a value type. The (string)null is unnecessary, but, consistency?
Admin
Bit columns are converted to boolean values by ADO.NET, so ToBoolean works in this case.
Admin
Not sure what you mean by that. Like others said, people don't poop flour, and bread isn't metabolized into flour before flour gets consumed by your system, in fact, flour cannot be consumed by our bodies, if you are raw wheat or flour, it'd go straight through and you'd have the flatulence of the century.
Addendum 2019-04-15 19:07: Ate not are, raw***
Admin
Oh, a perl programmer that switched to c#.
Admin
Ahh. It's been ages since I had problems with that, and assumed that what was true for me in 2006 using OleDb on top of a Sql Server 2000 back-end is still true in 2019. Refreshing to have my assumptions questioned every now and then, thank you. ;-)
Admin
I always preferred the more verbose, but explicit, dr.GetInt32(dr.GetOrdinal("int_32_column")) . There are even overloads for nullables - dr.GetInt32OrNull(dr.GetOrdinal("int_32_nullable_column")) that returns int? instead of int. Just because the string indexer is handy doesn't mean it's useful. :)
Admin
To get our C# is/as straight:
has worked since C# 1.0.
Starting with C# 7.0, that can be reduced to
Admin
so nice info
Admin
this is insane
Addendum 2024-05-15 01:35: Generally with regards to documents, it helped me a lot that I found writing specialists in my time. Generating text is also very important and you can't go anywhere without it. By the way, if you are interested, there is a typing company here and you can familiarize yourself with their services in detail. Maybe it will come in handy someday too.