× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.