On Tue, May 13, 2008 at 7:51 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> for version 3.6.0 we are considering a behavior change in which a call > to sqlite3_close() will silently and automatically call > sqlite3_finalize() on all outstanding prepared statements. > > D. Richard Hipp > [EMAIL PROTECTED] > > We would be very much in favor of this change. While calling sqlite3_close() without first finalizing all statements is a programmer error, if this occurs returning SQLITE_BUSY doesn't help much, it seems to compound the problem. We actually run into this problem a lot recently after some new features have exponentially increased the concurrent access in our application. the sqlite3_close() error occurs for us as a secondary error. Usually we get db locked first, and then fail to finalize the statement (our bad), but then it's compounded when sqlite3_close() fails. Unfortunately due to how connection pooling works in SQLite.NET this sqlite3_close() failure ends up happening on a garbage collector thread which in MS's infinite wisdom leads to a full application crash (at least it did initially--we've fixed that since this started). Interestingly, we're getting these errors in SQLite.NET which Robert said earlier in this thread already handles finalizing dangling statements. We're not using the official SQLite.NET distribution, we have some small modifications, but the code he mentioned is in place in the version we're using and is untouched. Thanks, Sam -- ----------------------------------------------------------------- We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer. Position is in the Washington D.C. metro area. Contact [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
