On 25 May 2009, at 7:42pm, Sam Carleton wrote: > 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?
Yes. That is one way of handling the problem. Bear in mind that your database engine doesn't know anything about how many lines you want to fit on the screen at once: that is your application's problem and nothing to do with the data. > 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. Ah, for a kiosk system, your original solution is better. Quite right. On 25 May 2009, at 9:32pm, Sam Carleton wrote: > I hear you that paging should be frontend logic, normally. The > problem is that I have a *DYNAMIC* record set that is constantly > changing: On 25 May 2009, at 9:53pm, Teg wrote: > Are you planning on periodically updating the display as the user > interacts with it? Have items pop in and pop out again as they're > added or deleted? From your description, the data displayed in the GUI > will go stale very quickly. The problem is even worse than that. There are three common approaches: A) Do the search when someone starts first asks for the list. Ignore all changes to the data until they've exited the list and gone back in. B) Each time the user moves from page to page, reflect changes to the data. C) Constantly update the display to show changes in the data even if the user isn't hitting any keys. They're all doable, but you're going to have to decide which of these you want to do. I've done (C) in a PHP/AJAX solution and it wasn't too hard: you have to constantly check to see if any changes have been made to the table. But it places a lot of load on the server and requires some extremely 'cheap' method of checking to see if any changes have been made. Be aware that using just one 'SELECT' gives you solution (A): the command makes a table in memory which doesn't change even if the data changes before you've got all the rows from the response. (B), on the other hand, has a number of problems if your users expect to see every record as they're paging through. For instance, suppose you're showing 10 records per page. Your user is on the first page when someone deletes the tenth record. Does this shift record 11 to the first page ? If so, then when the user hits 'next' do they miss the eleventh record ? Another possibility: the user is viewing the second page when someone deletes the first five records in the list. The user now hits 'previous'. Do you now show just five records on the display, or do you show five records again ? Questions like the above are reasons I don't like paging solutions for live data. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
