Sent from my iPhone
On Oct 13, 2011, at 12:45 AM, Wolfgang Stöcher <[email protected]> wrote: > From the docu of sqlite3_finalize: > "The application must finalize every prepared statement [1] in order > to avoid resource leaks." > Ok, fine. But the given reason(s) seem not to be complete. After > preparing and executing the SQL command "PRAGMA page_size;" without > finalizing the prepared statement, all tables seem to be locked (at > least any "DROP TABLE"-command fails). See the attached code-sample > for reproducing this behaviour (in the second call of testSQLt3 with > callFinalize=false). > When running into this problem I was looking into the wrong > direction for some time ... Did you reset the statement? Regardless of the statement you need to release the locks. This requires calling _reset or _finalize (which calls _reset). > The code also demonstrates a second "inaccuracy" that has cost me > some time: when sqlite3_step returns with SQLITE_ROW, sqlite3_errmsg > gives "unknown error" instead of something like "row available (no > error) The docs are quite clear that the return value of _errmsg is undefined if the last SQLite API call succeeds. SQLITE_ROW is not an error condition. -j > SQLite is a great piece of software. Maybe these hints help others > to be even more effective with SQLite. > Thank you for reading, > Wolfgang > > > Links: > ------ > [1] http://www.sqlite.org/c3ref/stmt.html > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
