Thank you. I've finally found the problem also thanks to error message. I haven't called sqlite3_reset() after SQLITE_BUSY so retrying step() returned MISUSE. But what to do if I'm fetching the rows for SELECT statement? Reset() would put me to beginning. Can SQLITE_BUSY (or _LOCK) occur after fetching of 1st row anyway?
It would be nice to give some example of robust error handling after sqlite_step() at the web page to show what to do for various errors. (Errors are not described in detail in the documentation, only their cause but not appropriate retry action). But users are reporting also other strange errors after sqlite_step() which I cannot reproduce, like: - SQLITE_NOMEM (after "Select count(*) where...". I don't believe there is really no free memory, I cannot see any memory leaks in application, whole database file has maybe 10-20 MB). How to handle this? - SQLITE_CANTOPEN - I've added the same handler for this - Sleep(...), retry. Is it correct? Do I need to call reset() too? - SQLITE_ERROR after COMMIT although I'm using prepare_v2() which is documented to return specific error code instead of SQLITE_ERROR. reset() returned the same code. Thank you! On May 13, 2008, at 7:57 AM, [EMAIL PROTECTED] wrote: > > I‘m running ATTACH database on SQlite 3.5.8 on windows. > I‘m opening one database > file and attaching the second one. > On my computer it works, but it fails at other computer. The > database is opened in more > than one thread (it is failing in worker thread). > sqlite3_step() returns SQLITE_MISUSE , but _sqlite3_errmsg() returns > "database is locked". > What can be the problem? My guess is that SQLITE_MISUSE is being returned when you try to do something with a prepared statement that has been finalized or a database connection that has been closed. The error checking to detect these things and return SQLITE_MISUSE is probabilistic - it is not guaranteed to succeed. But when it does, it is helpful in finding application errors. SQLITE_MISUSE returns do not set the error message. So sqlite3_errmsg() will continue to return the previous error, whatever that was. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
