|
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, August 01, 2007 11:13 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Limiting SQL results returned
Yes that should work, but to those for which it might not
be obvious, with the _caveat_ that T1 generates a temporary
table of all rows in the original file [of the named fields &
expression]. From the original description it would not seem
to be an issue [given there might not even be five rows for
any one status], but... The number of rows might make such an
implementation prohibitive for some tables and/or environments.
For very large result sets, an alternate method might be
to use an external table function which returns a given
number of rows from that table for a specific key value.
That program could use row level access, to decide what rows
to return. Some index might be available and conducive to
generating a relatively quick sampling; although /random/
probably not nearly as easy as with rand() and ordering. If
the program is in its own activation group and can leave the
file open for the repeated calls for each status, the file
would be opened only for that named activation, thus avoiding
open overhead.
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.