AW: SV: Embedded SQL

... and it's a performance issue

In contrary to native I/O where always the complete record is accessed, with
SQL only the columns you selected are really read. So in one block read more
records can be accessed.

If you only select the columns you need, you may influence the query
optimizer to use a specific index. An index only access (the index contain
all fields that are used) is the optimal access method. Because it is not
neccessary to access other data than the data provided by the index.

Dynamic SQL may be very "dynamic", but for performance static SQL is much
better.
The access plan for static SQL is stored in the program object.
For dynamic SQL in RPG no ressources are stored, that means the access plan
must be determined for each job and each user.
A system-wide statement cache attempts to help with the reuse of access
plans for Dynamic SQL requests.

Birgitta

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Alan Campin
Gesendet: Donnerstag, 12. Mai 2005 20:06
An: RPG programming on the AS400 / iSeries
Betreff: RE: SV: Embedded SQL


Have to agree 100% with you there. Defeats the whole purpose of using SQL.
Data base independence. SQL should never bring anything in except what it
needs.

-----Original Message-----
From: Wilt, Charles [mailto:CWilt@xxxxxxxxxxxx]
Sent: Thursday, May 12, 2005 9:52 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: SV: Embedded SQL


Good point Joel, I for one wasn't aware of it.

However, it could still be a problem since depending on such behavior
assumes that columns will be added to the end of the file, unused columns
will never be removed and in general the order will never change.

If you really need every column, maybe using select * could be excused.  But
even then, it's simply the lazy way out.  It doesn't really take that much
effort to get a list of the fields a file.  What to me is inexcusable, is
the use of select * when you don't actually need all the fields.

Just my .02.

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121


> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Joel Cochran
> Sent: Thursday, May 12, 2005 7:32 AM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: SV: Embedded SQL
>
>
> On Thu, 2005-05-12 at 16:07, Wilt, Charles wrote:
> > Note however that while I've been guilty of using select *
> in an embedded SQL statement myself, it is _NOT_ recommended.
> >
> > Basically, if you use select *, and the file changes then
> you need to recompile the program.
>
> That depends on what SQLSTT condition you are testing.  If the file
> changes, the SQLSTT will be '01503', so if you are testing
> for = '00000'
> then this statement is true, but if you are testing for <>
> '02000' then
> it should continue to work.
>
> > Related is of course the use of customer_ds as an
> externally defined DS.
>
> Since this was copied at compile time, it should continue to work.
>
> Joel
> http://www.rpgnext.com
>





--
This is the RPG programming on the AS400 / iSeries (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.