- You have another open operation or transaction which has not been
committed or finalized or in some way completed.
If I only have one connection, there can't be another uncommitted transaction?
Well there can be, which would cause a BUSY signal. Unless you've had success beginning the new
Thank you all very much for your answers..
On Mon, Jul 22, 2013 at 9:07 AM, RSmith wrote:
> - You have another open operation or transaction which has not been
> committed or finalized or in some way completed.
If I only have one connection, there can't be another
On 22 Jul 2013, at 7:28am, Jesper Baekdahl wrote:
> there should not be anything holding a
> lock.
Please check the return values of all the sqlite3_ API calls before the one
which is getting SQLITE_BUSY, even those which are apparently working. For
instance, do not do
On Mon, Jul 22, 2013 at 3:48 PM, Simon Slavin wrote:
> assert(sqlite3_finalize(S) == SQLITE_OK)
>
Nononono - in non-debug builds assert() is compiled out, so the above
disappears.
(Been there, done that!)
--
- stephan beal
Hi Jesper, the code you posted is not the offending code, it's just the symptom of a problem happening somewhere else. We will need
to see the other operations also done by the DB code to know what goes on with it, but from some experiences on the list the
following is likely:
- You have
Hey everybody.
I'm getting SQLITE_BUSY on sqlite_step on insert statement, that is
part of an explicit transaction of multiple statements. There is only
1 thread and 1 connection, so there should not be anything holding a
lock.
It does not happen very often, so I'm having a hard time debugging
6 matches
Mail list logo