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
