|
Shannon O'Donnell wrote:
midrange.com
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.
