|
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-2024 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.