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



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

Smith, Nelson wrote:
That's what I thought, Paul.   However, if I put the select field in front
of the keys (as the first key) and then did READE on the data to be selected
plus the normal keys, wouldn't I get the same benefit as DYNSLT without the
run time hit?


-----Original Message-----
From: Paul Tuohy [SMTP:tuohyp@attglobal.net]
Sent: Thursday, February 06, 2003 11:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: Database Access Path Question

Nelson,

If the two logicals have the same keys and select field, but select on different data in that select field they will NOT use the same access path. The access paths will only contain the keys of the records that satisfy the selection criteria.

If you specify DYNSLT, then the selection criteria is ignored (in regards to the access paths), so the access path will be shared between the two logicals (since the key definition is identical. You will take the selection "hit" at run time, when you use the access path.

HTH

Paul Tuohy

Smith, Nelson wrote:

The DYNSLT discussion is interesting, but doesn't directly address my
original question:

If two logicals have the same keys and select field, but select on
different

data in that select field, will they use the same access path, part of
the

access path, or not at all?


-----Original Message-----
From:	Steve Richter [SMTP:srichter@autocoder.com]
Sent:	Thursday, February 06, 2003 10:35 AM
To:	Midrange Systems Technical Discussion
Subject:	RE: Database Access Path Question

It depends on how many records meet the selection criteria. One factor
that
will always favor dynslt is that data mgmt can select records much

faster

than rpg code can.

accpth(*rebld or *dly) is another option.  Create standalone logicals

w/o

dynslt.  If they are used once a week in batch or if conditions permit

in

an
online appl, tell the system to *DLY accpth maint or *REBLD the accpth
with
the file is opened.

Steve

-----Original Message-----
From: midrange-l-bounces@midrange.com
[mailto:midrange-l-bounces@midrange.com]On Behalf Of David Dunfield
Sent: Thursday, February 06, 2003 10:12 AM
To: Midrange Systems Technical Discussion
Subject: RE: Database Access Path Question


DYNSLT may be an option, but we have experienced less than great
results using dynslt in reading records. It does work, but it still
reads all records in access path to select only those DYNSLT.


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



**************************************************************************
**************************************************************************
********************************************************

This message originates from Lincare Holdings Inc. It contains
information which may be confidential or privileged and is intended only
for the individual or entity named above.

It is prohibited for anyone else to disclose, copy, distribute or use
the contents of this message.
All personal messages express views solely of the sender, which are not
to be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@lincare.com or (800) 284-2006.

**************************************************************************
**************************************************************************
********************************************************

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list

To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.