|
I prefer to avoid %KDS as well as KLIST....i love the inline keys... Thanks, Tommy Holden -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris Sent: Wednesday, February 28, 2007 6:55 PM To: rpg400-l@xxxxxxxxxxxx Subject: Re: CHAIN Versus SETLL and READ When Data Needed Shannon O'Donnell wrote:
Key1 Klist
Kfld Fld1
Kfld Fld2
Kfld Fld3
Key2 Klist
Kfld Fld1
Kfld Fld2
CHAIN does seem better if you are always going use the data from a found
record. But don't take my opinion too seriously because I'm not expert
in the database; maybe there are scenarios (such as sparse keys) where
SETLL is faster than CHAIN (or vice versa) when the record is not found.
(Although a later post in this thread quotes from the manual saying
that sometimes a CHAIN is faster than a SETLL with sparse keys ...)
Aside from the CHAIN vs SETLL issue, you can improve your key lists by
using a key data structure, and then using %KDS(keyds:3) or 2 or 1. (It
would be more self-documenting than the KLISTs, even aside from your
somewhat devious use of Key1 as the name for the 3-key klist and Key3 as
the name for the 1-key klist :) You could use a list of keyfields like
Dennis suggested; but I think the keyds is _slightly_ better than a list
of keyfields _in this case_, since it's a bit easier to see that the
same key ds is being used for each CHAIN in the group (only one name to
check vs a list of 3 names or values).
D keyds e ds extname(file:*key)
/free
keyds.fld1 = something;
keyds.fld2 = somethingelse;
keyds.fld3 = whatever;
chain %kds(keyds:3) file;
if %found
...
else;
chain %kds(keyds:2) file;
if %found
...
else;
chain %kds(keyds:1) file;
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.