Eduardo <[EMAIL PROTECTED]> wrote:
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
first sqlite3_step succeeds, an implicit transaction is started
(I assume there are no explicit transactions
At 14:27 06/11/2005, you wrote:
Eduardo <[EMAIL PROTECTED]> wrote:
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
always a change. Also that way you don't waste time in rerunning the
affected transactions.
Eduardo <[EMAIL PROTECTED]> wrote:
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
always a change. Also that way you don't waste time in rerunning the
affected transactions.
It is indeed locked as you
D. Richard Hipp wrote:
> "Ulrich Telle" wrote:
>> Sure, it would be nice if SQLITE_SCHEMA errors could be handled
>> internally by SQLite, but I think it's a non-trivial task to handle
>> this kind of error.
>>
>> When I created my SQLite C++ wrapper wxSQLite3 I thought about handling
>> SCHEMA
Ulrich Telle <[EMAIL PROTECTED]> wrote:
Sure, it would be nice if SQLITE_SCHEMA errors could be handled
internally by SQLite, but I think it's a non-trivial task to handle
this kind of error.
For INSERT, UPDATE or DELETE a simple retry might be a good choice.
But how often should the retry take
Ulrich Telle wrote:
In case of a SELECT statement the situation is still more complex. The
SCHEMA error could happen after reading several result rows. If you would
then redo the query automatically it would start from scratch delivering the
already read rows again. If your application code
> > Suppose this where to change in version 3.3.0 so that the
> > actual error code was returned by sqlite3_step().
That would be a good thing, since it would allow appropriate reaction at the
right time and the right place.
> > Then when a schema change occurred, the statement was automatically
k [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 03, 2005 12:01 PM
> To: SQLite
> Subject: [sqlite] Re: Request for comment: Proposed SQLite API changes
>
>
> Fred Williams wrote:
> > Thanks. I guess I never considered using two different releases of
> > any p
Fred Williams wrote:
Thanks. I guess I never considered using two different releases of
any product within the same executable. Wonder how many use this
feature and why?
SQLite2 and SQLite3 have incompatible database formats. Neither can read
the databases produced by the other. One might
9 matches
Mail list logo
