Hi,
Just as a side note in case someone tries this...if you do a SELECT
directly from a SELECT/OMIT LF you'll be forcing the SQL to the CQE..which
is dog slow compared to SQE...
Even worse:
If you define logical files with select/omit clauses over your physical
file, all SQL statements that use this physical file (even without
specifying directly a logical file with select/omit) are routed to the CQE
(classic query engine) and cannot profit from the advantages of the newer
SQL Query Engine (SQE).
... At least as long as you won't change the option IGNRORE_DERIVED_INDEX in
the QAQQINI file to *YES and use this changed QAQQINI file.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Holden Tommy
Gesendet: Friday, April 20, 2007 16:31
An: Midrange Systems Technical Discussion
Betreff: RE: SQL logical file equivalent
That's a good approach...for RLA. For SQL processing I'd say just create a
view with your selection criteria and just handle ordering in your SQL
statement in the RPG program. With SQL processing you don't really *need* a
select/omit LF. Just as a side note in case someone tries this...if you do a
SELECT directly from a SELECT/OMIT LF you'll be forcing the SQL to the
CQE..which is dog slow compared to SQE...
But I have used both approaches for files in the past and they both work
great. In some client shops they do not have DB2/SQL product so I still use
the field list LF you're talking about.
Thanks,
Tommy Holden
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Friday, April 20, 2007 9:18 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL logical file equivalent
Why not do that?
I was trying to say (perhaps poorly <G>) that you SHOULD create your logical
files by explicitly specifying the fields you want. You should NOT create
the LF by omitting the field list and allowing all table columns to flow
into the LF.
I'm suggesting this approach so your 3GL RLA access is isolated from any
table changes in the base table. If you omit the field list and just inherit
the complete field list into the LF than the addition of a new column to the
base table will result in a change in the format level id of the LF and
you'll have to deal with that impact -- something I'm trying to avoid.
Make sense?
-Walden
midrange.com
