- wrote: > After having used the OFFSET and LIMIT 1 method (in conjuction with a > userdata listview) and finding a past post into this forum describing it as > a rookie mistake I'm now trying to implement the "scrolling cursor" method > in that same post.
Are you using a list view, or paging? The scrolling cursor method is appropriate only for the latter. The easiest way to handle a list view would be to read the primary key of _all_ records in the correct order into your application. If the amount of data isn't too large, OFFSET/LIMIT works just fine. > For the above method to work for any database it means I need, for > each-and-every next/previous page request, to send *all* the bottom/top > records data back to the SQLite engine so it knows where to continue. Only data in those columns that you are using for sorting. (But those must be a unique key for the records.) > 1) Is it possible to refer to the columns in a kind of shorthand (index > perhaps) ? No. > 2) Is it possible to have the SQLite engine initialize and remember certain > WHERE and ORDER clauses (without creating another database please :-) ), so > they can be used again-and-again (for the duration of a connection). Compiled statements can be reused (and the SQLite database drivers of many languages have a statement cache). However, this is unlikely to be a bottleneck. > 3) Is it possible, for the above 'scrolling cursor' method, to refer to a > starting record other than by sending the exact data of such a record back > to the SQLite engine ? No. But SQLite has no client/server communication overhead. Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
