sqlite3_step() is great for scrolling forward through a result set.
Is there a way to scroll backwards?
If not, did anyone try implementing it?
(I guess that the indexes would need backward pointers in order to do it.)
Clive
--- Richard Klein <[EMAIL PROTECTED]> wrote:
> My understanding is that, even with all the above
> features _OMIT_ed, SQLite 3 is still about twice
> the size of SQLite 2.
With the majority of options omitted, I was able to build a functioning
180,568 byte x86 linux sqlite3 binary. It is linked
Richard Klein <[EMAIL PROTECTED]> wrote:
>
> My understanding is that, even with all the above
> features _OMIT_ed, SQLite 3 is still about twice
> the size of SQLite 2.
>
> It you don't think that's true, let me know:
I don't think that is true. One x86, SQLite2 and
SQLite3 are roughly the
Clive.Bluston-cPKiotmf5pXN/[EMAIL PROTECTED] wrote:
sqlite3_step() is great for scrolling forward through a result set.
Is there a way to scroll backwards?
Store the ROWIDs of the records you've seen so far, retrieve each record
by its ROWID as needed. Or, just store complete rows.
Igor
WIESEN Bruno <[EMAIL PROTECTED]>
wrote:
I have another problem, I would like to create an unique index that
rollbacks on conflict...I've read in the book "The definitive guide
to SQLite" that
it was possible by specifying a conflict clause. What I did but I
have an error when creating the index
Hello,
Sorry for yesterday, I made a mistake in my code and consequently no
messages were displayed when encountering a constraint violation !
But now it does...
I have another problem, I would like to create an unique index that
rollbacks on conflict...I've read in the book "The
On Thu, 4 Oct 2007 21:35:30 -0500, Andy Goth wrote
> (See my original proposal writeup at the bottom of
> http://wiki.tcl.tk/2633 for more details.)
I made a significant update to the bottom of said page. I'll briefly cover it
here as well. Basically I revise my proposal to be less generic, to
"Andy Goth" <[EMAIL PROTECTED]> wrote:
> On Thu, 4 Oct 2007 21:35:30 -0500, Andy Goth wrote
> > (See my original proposal writeup at the bottom of
> > http://wiki.tcl.tk/2633 for more details.)
>
> I made a significant update to the bottom of said page. I'll briefly cover it
> here as well.
On Fri, 05 Oct 2007 15:20:41 +, drh wrote
> "Andy Goth" <[EMAIL PROTECTED]> wrote:
> > http://wiki.tcl.tk/2633
>
> I suggest you go head and write a short TCL procedure to
> accomplish the same thing.
Like this?
proc sql_expand {varname} {
upvar 1 $varname var
set result [list]
You really should be using an SQLite-specific quote function
somewhere. But ... I don't see one in there (I'd have expected it to
be something like [db quote $arg]). You could work around it by doing
something like [db eval {select quote($arg)}], but that feels clunky.
The quoting you're using
I am trying to use PHP and SQLite on N800 Nokia Internet Tablet - a great
handheld Linux based computer, but not exactly Linux (uses Maemo). That
means compiling is not an option for me, and most Linux things are 'ported'
over.
I can create a new database and insert from both command line and
"Andy Goth" <[EMAIL PROTECTED]> wrote:
> On Fri, 05 Oct 2007 15:20:41 +, drh wrote
> > "Andy Goth" <[EMAIL PROTECTED]> wrote:
> > > http://wiki.tcl.tk/2633
> >
> > I suggest you go head and write a short TCL procedure to
> > accomplish the same thing.
>
> Like this?
>
> proc sql_expand
"Scott Hess" <[EMAIL PROTECTED]> wrote:
> You really should be using an SQLite-specific quote function
> somewhere. But ... I don't see one in there (I'd have expected it to
> be something like [db quote $arg]). You could work around it by doing
> something like [db eval {select quote($arg)}],
On Fri, 5 Oct 2007 09:41:27 -0700, Scott Hess wrote
> On 10/5/07, Andy Goth <[EMAIL PROTECTED]> wrote:
> > proc sql_expand {varname} {
> >upvar 1 $varname var
> >set result [list]
> >foreach elem $var {
> > lappend result '[string map {' ''} $elem]'
> >}
> >return [join
bizshop <[EMAIL PROTECTED]> wrote:
>
> So I think it is creating databases in 3.3.7 - is that incompatible with
> 3.3.5?
>
Except for corner cases (such as using language feature from one
version of SQLite that did not exist in a different version) all
versions of SQLite that being with "3" are
As drh indicated, you're already doing what any quote() function would
be doing, so it sounds like you're safe.
My general tendency is to assume that anytime I implement something in
parallel to another implementation, no matter how trivially obviously
identical the implementations are, at some
> 3.0.0 is compatible with 3.5.1 and everything in between.
Minor caveats if you happen to use different versions of sqlite libraries
accessing the same database files:
- Default databases created with versions 3.3.0 through 3.3.6 cannot be
read by versions of sqlite from 3.0.0 through 3.2.8
> - If you VACUUM a 3.3.0 - 3.3.6 database in a later sqlite version it
> will change the sqlite file format to the sqlite version of the program
> that issued the VACUUM, and versions 3.3.0 - 3.3.6 will not be able to
> read the VACUUMed database.
My mistake. The above is wrong. This
[EMAIL PROTECTED] wrote:
> sqlite3_step() is great for scrolling forward through a result set.
> Is there a way to scroll backwards?
> If not, did anyone try implementing it?
> (I guess that the indexes would need backward pointers in order to do it.)
>
This issue keeps coming up so I did a wiki
[EMAIL PROTECTED] wrote:
sqlite3_step() is great for scrolling forward through a result set.
Is there a way to scroll backwards?
If not, did anyone try implementing it?
(I guess that the indexes would need backward pointers in order to do it.)
This issue keeps coming up so I did a wiki page.
My understanding is that, even with all the above
features _OMIT_ed, SQLite 3 is still about twice
the size of SQLite 2.
It you don't think that's true, let me know:
I don't think that is true. One x86, SQLite2 and
SQLite3 are roughly the same size.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Hello all,
I am seeing SQLite crashing during execution
of a SELECT statement when I make the page
cache very small (40 pages).
When I bump the cache up to 50 pages, the
problem goes away.
The problem only occurs on my RISC platform,
not on my x86-based platform. Also, I am
using SQLite 2
22 matches
Mail list logo
