Re: Working with tables, best method

With standard data management you essentially hard-wire your access to the data. If you use a chain by key with lock and then update and the index is deleted after you compile your program, your program will fail. With SQL your program will continue merrily on it's way. With SQL there will also be some (perhaps minimal) validation -- is the index really the way to go or should a table scan be used due to the underlying data characteristics? Is there a better index to use than the one when the access plan was initially determined? These optimizations and added flexibility imply some level of additional code path, which does not occur in your hard-wired scenario.

Bruce Vining


Luis Rodriguez <luis.rodriguez2@xxxxxxxxx> wrote:

--- rpg400-l-request@xxxxxxxxxxxx wrote:

------------------------------

message: 3
date: Thu, 14 Feb 2008 17:42:37 -0600
from: Joe Pluta
subject: Re: Working with tables, best method

I stand by the fact that single record chains and updates
still
outperform SQL.

<....>
Joe,

(Not trying to begin a long thread here, just being
curious?)
Although, of course, the decision to use either SQL or RPG
(or combination of both) is a business decision, I concur
that Single Record Access (SLA) in RPG is always faster
than SLA in SQL.

My question is, why is this so? If I work with SQLRPGLE,
IBM translates my SQL instructions to an intermediate code,
before compiling my program. Couldn't it be possible to use
a special SQL instruction (e.g. SELECT * FROM TABLE WITH
SLA) and then have the precompiler (either RPG or the DB
interpreter) convert it to a CHAIN (or UPDATE)?. Just
wishful thinking, I know, just wondering?

Regards,
Luis Rodriguez


Luis Rodriguez

IBM Certified Systems Expert
eServer i5 iSeries Technical Solutions