• bvs23bkv33 (unregistered)

    you should declare sql descriptor area, alloc memory for every data type in prepared statement and only then access data

  • Little Bobby Tables (unregistered)

    I love the way that it's written in upspeak?

  • Mike Rosoft (unregistered)

    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.

  • Roman (unregistered)

    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.

  • PenguinF (unregistered)

    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.

  • (nodebb)

    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.

  • Decius (unregistered)

    Why are you handling order identifiers as integers? Do you ever need to perform an arithmetic operation on one?

  • (nodebb)

    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.

  • symbiont (unregistered)

    // 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

  • snoofle (unregistered) in reply to Mr. TA

    Isn't that exactly what your body does when you eat said cake?

  • (nodebb)

    My favorite part is after he knows that value is null his return of “typed” null.

  • Bill Kempf (google)

    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 was as.

  • (nodebb) in reply to snoofle

    That's one of the arguments against Intelligent Design.

    I guess this code is also an argument against it.

  • (nodebb)

    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)

  • Scott (unregistered)

    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.

  • Tim! (unregistered) in reply to snoofle

    To the best of my recollection, I have never pooped flour.

  • Justus (unregistered)

    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.

  • (nodebb) in reply to Tomanek1

    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?

  • (nodebb) in reply to PenguinF

    Bit columns are converted to boolean values by ADO.NET, so ToBoolean works in this case.

  • (nodebb) in reply to snoofle

    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***

  • löchlein deluxe (unregistered)

    Oh, a perl programmer that switched to c#.

  • PenguinF (unregistered) in reply to Mr. TA

    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. ;-)

  • Daniel (unregistered)

    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. :)

  • (nodebb)

    To get our C# is/as straight:

    if(obj is string)
    {
           string str = obj as string; 
          // etc
    

    has worked since C# 1.0.

    Starting with C# 7.0, that can be reduced to

    if (obj is string str)
    {
    
  • (nodebb)

    so nice info

Leave a comment on “Typing for Types”

Log In or post as a guest

Replying to comment #504722:

« Return to Article