× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



IBM recommends DYNSLT if the number of records selected is over 80%. Here's the scoop from InfoCenter. Note the bit on access path sharing, but also note the use of "can" in many places - classic "it depends" stuff here.

Dynamic select/omit

With dynamic select/omit, when a program reads records from the file, the system only returns those records that meet the select/omit values. That is, the actual select/omit processing is done when records are read by a program, rather than when the records are added or changed. However, the keyed sequence access path contains all the keys, not just keys from selected records. Access paths using dynamic select/omit allow more access path sharing, which can improve performance. For more information about access path sharing, see Using existing access paths.
To specify dynamic select/omit, use the dynamic selection (DYNSLT) keyword. With dynamic select/omit, key fields are not required.
If you have a file that is updated frequently and read infrequently, you may not need to update the access path for select/omit purposes until your program reads the file. In this case, dynamic select/omit might be the correct choice. The following example helps describe this.
You use a code field (A=active, I=inactive), which is changed infrequently, to select/omit records. Your program processes the active records and the majority (over 80%) of the records are active. It can be more efficient to use DYNSLT to dynamically select records at processing time rather than perform access path maintenance when the code field is changed.

HTH

Vern

At 08:05 PM 2/6/2003 +0000, you wrote:
Correct.

This is really one of those "it all depends". By using the READE approach you are tackling the requirement through an application program - which means that the same solution has to be "coded" in every program that would require that selection path.

By using the DYNSLT approach, it is being done by the database manager ans all an application (RPG, SQL, Java etc.) has to do is open the file and process it.

As Steve pointed out, the use of DYNSLT can be quiet an overhead depending on the number of row returned.

FWIW, I would try the DYNSLT approach first ('cos I always prefer to do as much as I can in the database as opposed to within a program) and then, if I wasn't happy with the performance, go for the READE.

HTH

Paul


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.