On Tue, May 13, 2008 at 4:51 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > The currently documented behavior of sqlite3_close() is that when it > called on a database connection that has unfinalized prepared > statements is to return SQLITE_BUSY and fail to close the connection. > The rational is that we did not want a call to sqlite3_close() to > destroy sqlite3_stmt* pointers out from under other subsystems. But > 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. > > This is, technically, an incompatible change and we strive to avoid > incompatible changes. But we think it unlikely that this change will > cause any problems, and in fact we suspect it will likely fix more > bugs than it will induce. But before we move forward, it seems good > to submit the idea to the community of SQLite users and programmers. > > Does anybody have any thoughts on this proposed behavior changes for > the sqlite3_close() interface?
What will happen if you call things like this: db = sqlite3_open(...); sqlite3_prepare_v2(db, zSql, -1, &stmt, NULL); // ... sqlite3_close(db); sqlite3_finalize(stmt); ??? If sqlite3_finalize() will succeed, then this seems pretty reasonable to me. If sqlite3_finalize() will fail with a segfault or somesuch, that may be dangerous. My rational is that if someone is building a system which is abstracting SQLite, then it may be that the database handles and the statement handles will not have clear clean-up ordering (for instance in a garbage-collected system). One _could_ go ahead and create such an ordering by using refcounting or whatever is appropriate in your system, but it would also seem reasonable for SQLite to manage this. This may also come up with multi-threaded systems, where it could be challenging to convince another thread to finalize statements before calling close. I don't suggest that you should be able to do anything interesting with the orphaned statement handle at this point, other than finalizing it. I suppose it would be nice if all statement-handle functions would start throwing SQLITE_MISUSE or other appropriate error code. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
