RE: Java code help...

>>BTW:  Your app will perform better if you use the column indexes instead
of
>>the column names.  Part of why using names instead of column indexes is
so
>>expensive is because you have to do a linear search of the names of the
>>columns in the ResultSet for just this reason.  If your ResultSet has
100
>>rows and you are fetching the 100th row with a column name, you could be
>>spending an order of magnitude more time in the driver figuring out what
>>the column index is over actually doing the work of getting the data.

>>Sorry, dude... I'm a JDBC driver writer... I have to say those types of
>>things to the application programmers.  :-)

As application developer I have to say that I would never advocate for my
team to access fields in a result set by index.  It may perform better,
but it is bad programming practice.  I never want to hard code in my
application where fields are sequentially  located in a result set.  My
team is currently working on release 4.0 of our application.  Fields may
move around from release to release and I'm not changing hard-coded field
indexes every release.  Additionally, SQL statements are stored in
property files and the application code does not know or care about the
details of the SQL as long as the fields it is looking for are in the
result set.

This is really similar to saying for RPG/400 and RPG/ILE that application
programmers should use internally described files (hard coding field
positions like RPG/II) because it performs better.  There are way too many
advantages to externally described files.

So with that argument in mind, it seems that JDBC driver writers are
writing the driver for application writers to use and should attempt to
make access by column name work efficiently.  Why not create an temporary
index of the fields using a hash of the name-- I don't see why you need to
do a linear search.

===
Marshall Dunbar
DPS, Inc.
marshall@dpslink.com
(317)574-4300 (800)654-4689
====