Re: MIDRANGE-L Digest, Vol 4, Issue 1127

[Joel Cochran <jrc@xxxxxxxxxx>]

On Fri, 2005-06-10 at 17:00, midrange-l-request@xxxxxxxxxxxx wrote:
> date: Fri, 10 Jun 2005 12:34:55 -0400
> from: Steve Richter <stephenrichter@xxxxxxxxx>
> subject: Re: Detached datasets and DRDA compliance
> 
> What I do know a little bit about is the programming side of this
> issue.  As much as I respect MS I am not sure how comfortable I would
> be coding large scale database apps in .NET.  My code consists of a
> lot of this sort of stuff:
> 
> row = new SessionHistoryRow( ) ;
> row.SessionId = reader.GetString(0);
> row.UrlReferrer = reader.GetString(1);
> row.PageCx = reader.GetInt32( 4 ) ;
> row.StartTs = reader.GetDateTime( 5 ) ;
> row.EndTs = reader.GetDateTime( 6 ) ;
> 
> I have snipped a lot, but basically to read a row from a table, you
> load up an "SqlCommand" object with the "select * from table where
> xxxx = yyy" statement. After running the SqlCommand your code gets
> back the dataset.  From the dataset you then run code that pulls the
> rows and columns out and into your program variables.  That is what
> the above code is doing.
> 
> The problem is, you refer to everything by ordinal value or literal
> column name.
>   reader.GetString( 0 ) ;  // get the value of column 0 in the current row.
>   reader.GetInt32( "OrderQty" ) ; // search for the column named "OrderQty" 
> ...
> 
> Your code also needs to know the data type of the column. Is it
> decimal, SqlMoney, integer, string, dateTime, ...   Hopefully Walden,
> our .NET guru, can correct me, but it appears to have a lot of
> potential for hard coding issues.

Steve,

There are much better ways!  First of all, hopefully you are
encapsulating your tables in classes.  This will hide most of the
complexity from any of the calling programs.  You could create constants
or Enums in your classes to represent the fields: I suppose you can call
this hardcoding if you want...

Second, you do NOT need to know the row names, types, or ordinals.  You
can get the ordinal values, column names, and column types easily.  Look
at the DataColumn class: it is automatically available to any DataTable
through the Column property.  And you can process all the rows in a
simple "foreach" loop:

foreach ( DataRow dr in myTable.Rows )
{
        // add code
}

Most of the time you do know the type of each COLUMN because you
probably know your database.  Just like in RPG, you know what the field
types are when you issue a READ or CHAIN!  This is not a big deal...