RE: Returning Record Sets from SQLRPGLE Web Services

the query requires the additional selection with OR logic against each

of the other keys

Yup, but only the ID needs to be passed into the procedure to get the
next page as you can get the other values (firstname, lastname) if you
have the id.

what would all of the overhead of an IDcol achieve
that a RRN() could not, for the same scenario?

How much overhead is there in a surrogate key? Plus, it doesn't change
w/reorgs or reloads. However, for the sole purpose of paging I think you
could use RRN just as well as a ID column.

-Walden

--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, August 13, 2008 1:24 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Returning Record Sets from SQLRPGLE Web Services

So the solution for a case where IDcol is not the first key, is
achieved by the *or* tests that were added in the example you gave,
beyond adding the selection of IDcol>savedIDcol to get the /next page/
of data; i.e. the query requires the additional selection with OR logic
against each of the other keys. That is what I would expect. I had
mistakenly thought the post about adding an identity column was implying

that somehow the IDcol could by itself solve the paging problem, but
that would only be true for otherwise unordered sets.

FWiW: If that was explained in the link given in an earlier post in
this thread, I would not know, as the link was to _pay content_ [best I
can tell, from my results in visiting the link].

I wonder though, what would all of the overhead of an IDcol achieve
that a RRN() could not, for the same scenario? The relative row number
is a similarly arbitrary value, as compared to an identity.

Regards, Chuck

Walden H. Leverich wrote:

How many queries, percentage wise, would actually be ordered by an
identity column ... such that the noted technique would be valid?

Actually, you can make this technique value in all cases, and it's
actually the only way to get repeatable results back.

Say you're using the select from select from select from... approach
over a customer table, and you're sorted on lastname, firstname. It
is possible, even likely, that you've got a number of Mike Smiths in
the database. Your order by would be "order by lastname, firstname"
yes? But what order are the duplicate Mike Smiths going to show up
in? Since you didn't specify then the order is not defined, and there
is _NO_ guarantee that they will come back in the same order next
time, so the Mike Smith with customer # 12345 may have been the
1001st row first time and missed the 1-1000 page and been the 999th
row the second time and missed the 1001-2000 page. Therefore...

Make your order by "order by lastname, firstname, customer#" and then
have the <ed> caller pass in the last customer # they received
(@LastNumber). Then you do this sort of thing:

select @lastname = LastName, @FirstName=FirstName from customer where
customer#=@LastNumber

select top 1000 * from customer
where
(lastname=@LastName and FirstName=@FirstName and
Customer#>@LastNumber)
or (lastName=@LastName and FirstName>@FirstName)
or (lastName>@LastName)