Ah, PAGINATION, that perenial problem.
Lots of ways to solve this, some simple, many as complicated as it gets.
If you are using sessions then you can store the required information to keep track of the pages in session vars.
If not then you have to store them in hidden fields on the html page.
Now you can work this in many ways:
1. store the whole query string and modify the LIMIT clause from page to page
2. store the values from the WHERE clause and the LIMIT clause to re-generate the query
3. calculate the Limit values for the next and last pages and embed them as values in your Next/Last buttons/links on the html page, along with the Where values in a hidden field
4. store the WHERE values and the page number and use a formula to calculate the Limit values.
My solution:
If you are displaying 20 results per page then query for 21: that way you know if there will be a next page: ie if you get 21 records back then there is at least 1 record to display on the next page. 😃
I store the Where values as session vars along with the page number and rows per page (rpp). I can then calculate the Limit values from the page number/rows per page thus:
LIMIT (rpp x (page - 1)), (rpp + 1)
This works cos the offset of the rows starts at 0, ie page 1 displays 0-19 so page 2 displays (20 x (2-1)) = 20-39 , page 3 displays (20 x (3-1)) = 40-69 etc
I store the rows per page as a var instead of hard-coding it so that it can be reset without changing my code.
Thus, my html only needs to indicate back or forwards. Back then p in my formula = current page - 1, forwards = current page + 1
Bear in mind that users will rarely page through more than 3 or 4 pages so working out that there are enough records for 50 pages is just a waste of processing time. If you want to look fancy then just query for 4 times rpp and give links for next 3 pages if they exist.
Hope you follow this and that it helps. 🆒