Hmmm, I am guilty of not always stepping until I get SQLITE_DONE (I am
usually selecting by the primary key, and therefore know I will only get a
single result), but I make sure to always call sqlite_reset, so I don't
think that should be the issue.
On further reflection, I suspect it might be
On 13 March 2015 at 01:21, Dinu Marina wrote:
> You should be also aware of a more common pitfall: unclosed result sets.
> Any lock is held until you read PAST the last row or you call stmt_finalize
> (or the equivalent abstraction in your DBAL). Always close select
> statements.
Hi Dinu,
Am
You should also check, as R.Smith and Slavin pointed, that you don't
accidentally have a BEGIN [DEFERRED] somewhere, as that would trigger
exactly this behavior: it will lock on the first select (the first
step() actually)
On 13.03.2015 02:44, Simon Slavin wrote:
> On 13 Mar 2015, at 12:17am,
Na, it should be the same, everywhere I said finalize you can replace
with reset; I had this problem come over and over from people forgetting
to finalize (there was no intention to reuse the statement). But reset
is the same. My point is just that if you don't have explicit
transactions, a
On Fri, 13 Mar 2015 08:17:26 +0800, Barry wrote:
>On 13 March 2015 at 01:21, Dinu Marina wrote:
>
>> You should be also aware of a more common pitfall: unclosed result sets.
>> Any lock is held until you read PAST the last row or you call stmt_finalize
>> (or the equivalent abstraction in your
On 13 Mar 2015, at 12:17am, Barry wrote:
> On 13 March 2015 at 01:21, Dinu Marina wrote:
>
>> You should be also aware of a more common pitfall: unclosed result sets.
>> Any lock is held until you read PAST the last row or you call stmt_finalize
>> (or the equivalent abstraction in your
On 3/12/15, Barry wrote:
> On 13 March 2015 at 01:21, Dinu Marina wrote:
>
>> You should be also aware of a more common pitfall: unclosed result sets.
>> Any lock is held until you read PAST the last row or you call
>> stmt_finalize
>> (or the equivalent abstraction in your DBAL). Always close
There is also a more obscure side-effect exhibited by sqlite only: if
you issue consecutive unfinalized select statements, it never releases
the write lock (although they should be atomic), but it does trip the
deadlock mechanism; any writer in the wait will receive SQLITE_BUSY at
the very
You should be also aware of a more common pitfall: unclosed result sets.
Any lock is held until you read PAST the last row or you call stmt_finalize
(or the equivalent abstraction in your DBAL). Always close select
statements.
On Mar 12, 2015 11:40 AM, "R.Smith" wrote:
>
>
> On 2015-03-12 04:38
On 2015-03-12 04:38 AM, Barry wrote:
> Hello everybody,
>
> I have a situation where two processes are accessing the same SQLite
> database. One process only reads from the database, one process reads and
> writes.
>
> These processes keep a single database connection open for the lifetime of
>
Hello everybody,
I have a situation where two processes are accessing the same SQLite
database. One process only reads from the database, one process reads and
writes.
These processes keep a single database connection open for the lifetime of
the process.
It seems to me that once the reader
11 matches
Mail list logo
