I did some tests today and demonstrated that this problem goes away if the main thread is forced to sleep while the helper thread is running. Since the threads are operating on distinct databases, I don't think this should be necessary.
If I've misunderstood the level of thread safety provided by Sqlite, please tell me. Otherwise, I think this may be a Sqlite bug. Perhaps some confusion is resulting from the fact that my "distinct" databases actually share much in common (a schema, and one of the databases previously had the same name as the first but was renamed). I'd appreciate everyone's thoughts on this... I don't really want either thread to have to wait and it doesn't seem like they should have to. Also, I do plan to upgrade my version of Sqlite to whatever the latest is on the site (assuming I don't have the latest version already). I've only put that off because I'm dealing with a fairly brittle (and critical) app here, and I want to tread lightly. ________________________________________ From: Beau Wilkinson Sent: Tuesday, May 05, 2009 9:02 AM To: General Discussion of SQLite Database Subject: RE: [sqlite] sqlite3_prepare returns SQLITE_MISUSE Thanks for the reply. SQLITE_MISUSE would make sense in the scenario you describe. But it is difficult for me to see how I could be calling prepare with an unopened or closed connection. I am basically in the process of executing a series of statements against an open database that is exclusive to the thread. Everything succeeds until a random point. Is the database being closed somehow, and I am not realizing it? Or are my threads interacting in a way I've not considered? ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On Behalf Of Igor Tandetnik [itandet...@mvps.org] Sent: Monday, May 04, 2009 5:18 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_prepare returns SQLITE_MISUSE Beau Wilkinson <b...@mtllc.us> wrote: > Nevertheless, I am getting some very puzzling errors. In particular, > there are cases where sqlite3_prepare() is the first call to cause an > error, typically SQLITE_MISUSE. You are passing a bad (never opened, already closed) connection handle to sqlite3_prepare. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users The information contained in this e-mail is privileged and confidential information intended only for the use of the individual or entity named. If you are not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and delete any copies from your system. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
