On 8/30/07, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
From: Carl

Wouldn't using ResultSet#previous() accomplish the same thing as a READP?

Not if you go before the first record in the result set. With a logical
file, you can position by key and then do a read previous.

Then I would wonder if that ResultSet is the set of results you actually
needed?
Perhaps I was really wondering whether the RPG idiom of SETGT/READP is even
necessary when using sql, since you can determine the sort order and
collect a result set with the records you actually want in one request,
not two. For example, given a table with a key of a single integer, with records
1-5, where you wish to read record 4 through 1, in RPG you might write:

c setgt 4 SOMETABLE;
...now get the previous record, do until...
c readp SOMETABLE;
...etc...

in SQL you can simply request:
SELECT FIELDA
FROM SOMETABLE
WHERE KEY < 5
ORDER BY KEY DESC

in one operation. There is no need to even move backwards in the result set. If
you're actually only interested in the previous record, just add a LIMIT clause
and (in theory) it's even more efficient?

Though i'm really not sure why you would want to use this idiom in
sql. I think the
need for SETGT/READP arose from the inability to dynamically sort records
in RPG.

It's the fastest way to get the last record in a set without having to have
indexes in both directions.

Surely if written in RPG, but when writing code in java and using JTOpen
record level access, is the process of requesting a record then
reading the previous (emulating SETGT/READP) faster than issuing a
single sql statement?


Joe



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