From the settings panel for a page it is possible to set the pagination to display 10, 25, 50 or 100 records but by enabling the user to set the limit on a page the user is able to select 500 & 1000. Why is this?
Hi Craig,
Are you wondering why we cannot set 1,000 records as the default pagination? It’s for performance reasons, most likely. Getting 1,000 records anytime a view loads puts a strain on resources, so from a technical point of view it’s smarter to require the user to select this from a dropdown rather than make it a default.
However there’s a workaround—you can link to a page that displays 1,000 records. Instructions on how to do that are here: Is it possible to display more than 100 records at a time on a table, list, or search view? - Knack Knowledge Base
Hope this helps,
Ian
Knack Pros
Echoing my good friend Ian @KnackPros comments, this is exactly the reason I was given years ago by the Knack team.
Every time the user arrives on a page set to show 1,000 records it puts more demand on the server to load those records. The user then clicks into a record to view, then goes back and the page has to reload the 1,000 records again.
As a developer I’d always question my client as to why they need to see 1,000 records. Often it’s a spreadsheet throw back as they’re used to seeing thousands of rows in one worksheet.
In most cases users are trying to find a record so scrolling up an down should be replaced by search
Given the above you could argue that the page should load and show 10,000, 20,0000 or 300,000 records so the client could see “everything” in one view. This is fine if they like to scroll up and down a long list. 
I spent a long time with one client that had been using spreadsheets for many years, like me, who just scrolled and clicked “next page” until she got to the correct location. She just couldn’t adjust to using search. 
I agree, I can’t see why anyone would want 500 or 1,000 records to be displayed. My issue is that I want to display just over 100 records ( currently 132) with a total at the bottom of the outstanding balance column. At the moment, when users are viewing the page, which is currently set at 100 as the default, they are taking the total amount as the total outstanding not realising that in fact it is only the total for the records on that page.
1 Like
Hi @Craig_H
I understand your query more fully nowđź‘Ť
Currently you have 132 records which is pushing 32 of them onto page two, thereby only showing the running total for the first 100 records on page one.
I now see why you want to display more than 100.
Forward wind 12 months and this will likely be a lot higher than 132.
Two ideas spring to mind without code, as I’m not a coder.
Create a parent object and connect the table with 132 records to it as a child. You can then sum the line items from the Parent summary object.
You only need to have one field to “Sum” your line items in the Parent object. Just make sure you connect you line items object to the parent summary object.
You can then add a details view of this parent summary table to the page that has the table of all you line items.
If you format it to H2 bold it will be a really easy and obvious summary at the top of the page for all the line items irrespective of how many line items you have.
You can then limit the page to 50 or 100 records.
The other option is to drop in a pivot table above the table, less attractive but functional.
I’d always do the first option.
Apologies if you know this already 
1 Like
Thanks Carl for this, I will take a look.
