Re: Detached datasets and DRDA compliance

[Joel Cochran <jrc@xxxxxxxxxx>]

> date: Fri, 10 Jun 2005 16:15:53 -0400
> from: Steve Richter <stephenrichter@xxxxxxxxx>
> subject: Re: MIDRANGE-L Digest, Vol 4, Issue 1127
> 
> 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!

DataTable dt = myDataSet.Tables[ "TABLENAME" ];
int employeeOrdinal = dt.Columns[ "EMPNUM" ].Ordinal ;

Or if you are using a DataReader:
int employeeOrdinal = reader.GetOrdinal[ "EMPNUM" ];

Yes, you have to use the field name, but you do not have to hardcode the 
Ordinal values,
so if the field order changes you are still covered. If you changed a field 
name in a file,
RPG would bomb at run-time as well.  Yes, if you recompile it, RPG would
catch it and .NET wouldn't, but this is also true of Java, C, C++, Perl,
Python, PHP, and you-name-it-other-than-RPG.

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

See above.

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

The class code that I write generates a DataSet, then I simply bind the
DataSet to the DataGrid, no literals necessary.  I even cycle through
the DataColumns and create a dynamic DataTableStyle object to set column
widths based on content size.

What class code certainly does help with is only needing to correct any
such changes in one place.  If all your apps use your home-grown DLL to
process employee data, then there is only one code member to update.

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

Admittedly, I don't do ASP, but the .NET funcitonality should be the
same.

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

True enough as I stated in the first section.  But Zoned, Packed, and
Signed should all show up as System.Decimal in a DataSet.  As long as
the data is read in to the variable type the .Net App is expecting, it
shouldn't be a problem.  You can use the Convert.Toxxxx() feature to
convert from just about anything to just about anything.  Couple that
with DataColumn.GetType() and you should be able to dynamically handle
these little problems.  Again, do it ONCE in your class and then forget
about it.

Joel Cochran
http://www.rpgnext.com