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



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)

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.