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

On 6/10/05, Joel Cochran <jrc@xxxxxxxxxx> wrote:
> 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...

classes help.  But in the class code I still end up refering to
columns by their ordinals ( employee number is column 0, salary is
column 4, ... ) A potential nightmare in an enterprise application
when a new column is inserted into the database.   Using column name
is no great solution either because there is no compile time type and
name check for that sort of thing.  Change the name of a column in the
database, recompile the application code, .... no errors, at least no
compile errors!

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

You still need the column name, which is not syntax checked at compile time.

Class code does not help when populating a DataGrid.   DataGrid is
great, you just drop it on the web page, then use literals to specify
the columns of the grid and how those columns map to columns in the
database tables.   All hardcoded.

<asp:DataGrid id="TableGrid1" runat="server" AllowPaging="True" PageSize="10"
<asp:BoundColumn DataField="OptionName" HeaderText="Option
name"></asp:BoundColumn>
<asp:BoundColumn DataField="OptionText" HeaderText="Option
text"></asp:BoundColumn>
</asp:DataGrid>


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

in RPG, when I change a field in the database from zoned to packed,
the compiler will auto map the values for me.  If I change a data type
from Decimal to Double the compiler has no idea that this stmt:
    reader.GetDecimal( "OrderQty" )
is no longer correct.  I will only find out when the application bombs.

-Steve