Thanks for your reply Patrik,
Yes there are always two sides to the coin.
The problem is the time it takes to retrieve a large list of records.
Then most of the time the required information is in the first 100 to 200
records.
There are some lists that could be many hundreds of thousand records which
may even time out before the page is built unless the wait time is
adjusted.
My intention was to have a page size of 250 to 500 records or even more -
this should make the need to page much less frequent and the page load
time quite fast.
So in these cases some form of pagination is needed.
Another option is to have a date range selection that is limited to say 3
or 6 months worth of records, thereby limiting the number of records
returned and removing the need for pagination.
Where a list is never going to be more than a 1000 records i would just
build the entire list.
Any comments or suggestions welcomed.
Thanks
Don
From: "Patrik Schindler" <poc@xxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 26/09/2023 08:13 PM
Subject: Re: SQL Pagination
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>
Hello Don,
Am 26.09.2023 um 09:12 schrieb Don Brown via MIDRANGE-L
<midrange-l@xxxxxxxxxxxxxxxxxx>:
I have been reading up on options to implement pagination into some of
our
web enquiries.
No answer to your question, sorry. But…
Is there a compelling reason to implement pagination?
Personally I perceive a "paginated" list as a major nuisance. I can
comfortably scroll with the mouse wheel through a list no matter how many
entries, and find what I'm searching for with the browser's find command
very quickly and efficiently. With the increasing ubiquity if "paginating"
I find myself dealing with cumbersome and needless klicks to "next page"
more often than not.
Please think twice. Just saying.
:wq! PoC
midrange.com
