On Mon, May 25, 2009 at 2:31 PM, Simon Slavin <slav...@hearsay.demon.co.uk> wrote: > > On 25 May 2009, at 6:58pm, Sam Carleton wrote: > >> Example: Following the logic of the ScrollingCursor page, lets assume >> a total result set of 88 titles. If the lasttitle happens to be the >> 29th title, so the set that is returned is 30 through 34, how do I >> determine that this is the 6th page of a total of 18 pages? > > > You're going to have to know how many rows are displayed on a page. > When you get your initial results back from the table, count the > number of rows (or use the library function that returns it) and > divide one by the other. This gives you (more or less) the number of > the last page of results. > > As well as keeping track of which page you're on, keep the current > page number in a variable. Just modify it when they hit 'next' or > 'previous'.
So in the end, you are saying that it is completely and totally the responsibility of the frontend to keep track of the page number, correct? The result set should simply return a total count so that the # of pages can be calculated. Correct? > However, there's another way to do it. If you know that you're never > going to have more than a couple of hundred results, why display them > as pages at all ? Display them all, and provide a search function > which lets people see just the records which contain their search > field. This is faster and more efficient than asking your users to > wade through many pages. That is a very good question. The main reason is that my application is a kiosk system that can be run on a touch screen display. Paging is much easier than scrolling on touch screens. Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users