Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-23 Thread RSmith
- 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

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-23 Thread Jesper Baekdahl
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

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-22 Thread Simon Slavin
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

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-22 Thread Stephan Beal
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

Re: [sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-22 Thread RSmith
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

[sqlite] SQLITE_BUSY on rare occasions, single thread, single connection

2013-07-22 Thread Jesper Baekdahl
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