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 the
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 I
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, B
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 rea
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 D
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 DBAL).
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 se
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 mome
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 A
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
> t
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 proc
11 matches
Mail list logo
