- 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 transaction, in which case it can be
the only open transaction. Do all prior end transaction operations return SQLITE_OK?
Bottom line is this: SQLite can't report a BUSY signal if it isn't actually
BUSY. Being busy means it is waiting to finish some open DB operation
(which only you could have started) and you have either not yet finished it
or released it of its responsibility, so pay good attention to where you
release/close the queries.
I only have a handful of prepared statements, that are reused by
calling sqlite3_reset in between queries. This should be good, right?
I don't need to finalize them before last use?
Well yes, at least it works for me this way, unless someone else here knows of a quirk with resetting statements which I am unaware
of. But, what I was trying to highlight, is that one or more of these other statements HAS to be not reset or not finalized, or
more simply, HAS to still have responsibility against them towards an open query. Do you check the return results of every
sqlite3_reset() statement? Do they all return SQLITE_OK? I once had an "If" statement that sidestepped a reset when an
sqlite3_step() returned an error, so the error situation remained open, etc.
Bottom line: If only one connection exists, and every created query pointer (prepared statement) was successfully reset or finalized
returning SQLITE_OK, then it is a physical impossibility for SQLite to return a busy signal (again, unless I am missing something).
So you need to find the one that fails when reset/finalized.
Also - even if you have multiple connections, like say you are viewing the dataset with a Database management tool while coding, it
should only ever fail when a table is actually locked, which should only ever happen at the very time you edit it from the other
connection, and also only if you don't have a timeout pragma set. Setting a timeout and testing it without getting errors, then
resetting it and getting errors again; is usually an easy test for me to ensure another connection is the culprit:
http://www.sqlite.org/pragma.html#pragma_busy_timeout
Last but not least, as most coders have experienced at some point - you may have an incorrectly sized buffer actually writing into
wrong memory locations, usually a silly glitch like sizing a MCBS character array to the length rather than the bytesize or
whatever, which means one inconspicuous bit of your code is corrupting the memory of another process. There are tools to check this
with in most dev environments, and it's not a likely fault, but if you have tested everything and it is correct, and things
happening start looking like "magic", then it's time for finding a memory bug.
Have a great day!
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
