I've done it a long time ago before discovering that limit/offset was not the way to go
http://www.codeproject.com/Articles/26938/AlphaView Anyway, it worked quite well even on slow pda. Best wishes Noel On 10 July 2014 15:19, - <mz2n6u7c.temp...@xs4all.nl> wrote: > Hello Clemens, > > > Are you using a list view, or paging? The scrolling > > cursor method is appropriate only for the latter. > > I'm using a report-style listview. And to be honest, I have no idea what a > "paging" component looks like (I'm using standard windows components). > > > 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. > > True. But as its my intention to create a generic SQLite3 viewer I have no > idea if the computer its used on will have enough memory to store such a > list, as the size of the database is unknown .... > > > Only data in those columns that you are using for sorting. > > (But those must be a unique key for the records.) > > :-) As for a generic viewer I have no control over that it means I need to > send *all* columns back, *in full*. (and yes, I see blobs creating a > problem > there). :-\ > Otherwise I either can get stuck (>=) or skip records (>) when the WHERE > field contains more than a pages worth of the same data. Already ran into > that .... > > > > 1) Is it possible to refer to the columns in a kind of shorthand > > > (index perhaps) ? > > > > No. > > Thats (too) bad. > > > Compiled statements can be reused (and the SQLite database > > drivers of many languages have a statement cache). > > How do I refer to a previously executed (and terminated) statement ? If > that is not possible, how is that cache of use to whomever needs to repeat > a > query ? > > > However, this is unlikely to be a bottleneck. > > Its not a bottleneck I'm worried about, it is having to cope with a > system/method/environment which demands me to do/send the same thing every > time I need something from it, or having to return data I just got from it. > It just bellows inefficiency to me. > > > No. But SQLite has no client/server communication overhead. > > I'm sorry, but I have no idea why you mention that overhead. > > The "overhead" I was thinking of is the one where the database has to > re-find a record it has just found and send me the contents of. Again, > inefficiency. Another "overhead" is my program having to keep track of > (possibly large ammounts of) data, only so I can send it back (a standard > listview only accepts upto, IIRC, 260 chars and discards the rest). > > What I was thinking about was something in the line of "continue/start from > rowID {ID}". > > Regards, > Rudy Wieser > > > ----- Original Message ----- > From: Clemens Ladisch <clem...@ladisch.de> > To: <sqlite-users@sqlite.org> > Sent: Wednesday, July 09, 2014 4:15 PM > Subject: Re: [sqlite] Questions from a novice - basic browsing of records > ina listview. > > > > - 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 > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Noël Frankinet Strategis sprl 0478/90.92.54 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
