Re: AW: AW: SQL null indicators when not all columns are null capable

Another point on this. SQL implements I/O as expensive program calls. File
I/O using procedure calls directly to the C api's but the SQL pre-compiler
has never been rewritten for the modern world so each I/O operation is an
expensive program call so the more you can reduce the number of expensive
program calls the faster it is going to perform and the best way to do that
is to fetch as many rows as you can or need instead of fetching them one by
one. Makes a big difference in performance.

One of my huge pet peeves with SQL pre-compiler. Jon has indicated in the
past that there was discussion within IBM of rewriting the mess but was
dropped in favor of just patching the old junk.

On Wed, Apr 14, 2010 at 2:50 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

The reason to use multiple row fetch versus single row fetch, is
to limit the /number of trips/ between the program and the database.
The smallest ratio for the number of trips to the number of rows
retrieved would typically provide the best performance for the
program, with regard to its database access processing.

For example, an analogy... One could remove separately each box
of canned food from a pallet rather than removing separately each
can of food from within each box on the pallet. Using the latter
method would, except for when there is only one can per box, require
more trips than when using the former method. As the number of cans
per box increases, so too would the impact of the trips as measured
in percentage of the overall work, to complete the task of removing
all of the cans individually from the pallet.

Regards, Chuck

Marc Couture wrote:

And what the reason to fetch multiple records at the same time?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.