On 1 Mar 2017, at 9:17pm, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
> I am not sure of all of the conditions which might result in "Database is > locked". For example, if the results of a query are being iterated through > and the reader stops iterating part way through the result set, might this > cause "Database is locked" for writers? If you do a sqlite3_step() for a statement then you absolutely must do a sqlite3_reset() or sqlite3_finalize() or both for that statement. Without it you haven’t finished processing the statement. Not doing this properly may not necessarily result in a lock which prevents writers (though it might), but it can can cause problems later. For instance, you can’t close a connection which still has active statements, and that means your database may still be open when your program quits. > Some of our C software is very good at doing this, and some C code is not > quite as good. Our Python code should be robust at reporting problems since > we are using APSW and Python exceptions. If possible, fix your C code. But you knew that. And there can be reasons why that’s not possible (legacy code you’re not allowed to change, libraries you can’t recompile). > We do capture output from sqlite's tracing facility, including error reports. Unfortunately, the tracing facility is triggered by your program doing an API call. If you don’t do the API call, you don’t get an error report saying what you did wrong. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users