|
On Fri, 2005-06-10 at 23:16, midrange-l-request@xxxxxxxxxxxx wrote: > date: Fri, 10 Jun 2005 15:25:19 -0600 > from: "David Morris" <David.Morris@xxxxxxxxxxxxx> > subject: Re: Detached datasets and DRDA compliance > > Joel, > > In the .NET and Java worlds you don't want to rely on the ordinal > position of columns and untyped data. Using column names is better but > pushes the problem into your application and is similar to using > program-described files in RPG. A better solution is to use a mapping or > ORM tool along with a strongly-typed DataSet in the .NET world or class > Collections in Java. That way you get compile-time feedback when things > change and also centralizes your data definition. > > David Morris I was merely showing that there are alternatives to what Steve's original thread implied: > 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. The "hard-coding" issue here just seems moot to me: in RPG, in order to use a field name I have to know the field name and the type... how is this different? [And before it comes up, I'll concede the point that the Compiler in RPG would catch such a change but DOTNET won't] The approach I outlined uses the field names once to dynamically get the Ordinals, so the ordinal numbers themselves aren't hard-coded. Ordinals will perform better, so this way you should get the best of both worlds. I'd also like to point out that as long as you aren't using "select *" then you are already in control of the ordinal values and field positions, but that is neither here nor there. Yes, strongly typed DataSets are probably a better way to go for applications that are designed for particular databases/tables. I was trying to point out that you do NOT have to know and/or hardcode everything about the fields in the DataTable. If the problem really is that the field names/types may change, then all I'm trying to say is that you can code around those problems. Joel http://www.rpgnext.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.