On 1 Jul 2012, at 3:36am, C M <[email protected]> wrote: > 1) locked database (due to using SQLite Database Browser to change a > database but not Saving it) > 2) sqlite3.OperationalError: SQL logic error or missing database > (happens very rarely. No idea why) > 3) sqlite3.OperationalError: disk I/O error (also happens very rarely. > No idea why)
You already know the cause of number (1). I bet the same thing is causing (2) and (3). One of the problems with reporting them here is that they are not SQLite errors (i.e. not one of the error codes listed here <http://www.sqlite.org/c3ref/c_abort.html> ) but seem to be errors generated by a framework or API you're using. If you're using SQLite Database Browser just to make trivial changes and do the odd SELECT, could you try using the SQLite shell tool instead, just for debugging purposes ? The shell tool was written by the same team who write SQLite itself, and we understand every little thing it does. If you get any errors while using it they will understand exactly what caused them. For instance knowing what might cause a locked database while using the shell tool is very simple: a BEGIN without a ROLLBACK or a COMMIT. It's far harder to figure out when a GUI might have the database locked. Lastly, to dramatically reduce the number of (1)s you get, use this call <http://www.sqlite.org/c3ref/busy_timeout.html> and set the timeout to a few seconds. The default timeout is zero, meaning that any locks of the database by a different process will immediately result in an error, which isn't what most programmers want most of the time. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
