Small. Fast. Reliable.
Choose any three.

This information is obsolete. You are looking at the CVSTrac source management system display for SQLite that was replaced by Fossil on 2009-08-11. The information shown here has not been updated since that cut-over. These pages are retained for historical reference only.

Error Code SQLITE_LOCKED (6): Database Is Locked

This error code occurs when you try to do two incompatible things with a database at the same time from the same database connection. For example, if you are in the middle of a SELECT statement and you try to DROP one of the tables being read by the SELECT, you will get an SQLITE_LOCKED error. Here is an example (using Tcl):

   db eval {SELECT rowid FROM ex1} {
     if {$rowid==10} {
       db eval {DROP TABLE ex1}  ;# will give SQLITE_LOCKED error

Note that an SQLITE_LOCKED error is distinct from SQLITE_BUSY (5). SQLITE_BUSY means that another database connection (probably in another process) is using the database in a way that prevents you from using it. SQLITE_LOCKED means the source of contention is internal and comes from the same database connection that received the SQLITE_LOCKED error.

Here are other reasons for getting an SQLITE_LOCKED error:

  1. Trying to CREATE or DROP a table or index while a SELECT statement is still pending.

    • Sometimes people think they have finished with a SELECT statement because sqlite3_step() has returned SQLITE_DONE. But the SELECT is not really complete until sqlite3_reset() or sqlite3_finalize() have been called.

  2. Trying to write to a table while a SELECT is active on that same table.

    • As of check-in [3355] (2006-08-16 after version 3.3.7) this is now allowed.

  3. Trying to do two SELECT on the same table at the same time in a multithread application, if sqlite is not set to do so. Anonymous adds: can someone please expand on the 'not set to do so' above? DRH replys: This third bullet item was added anonymously. I am not aware of any restrictions on doing two or more SELECTs from different threads at the same time, as long as each SELECT is happening in an independent database connection (that is: a separate sqlite3* object obtained from separate sqlite3_open() calls). As far as I know, the only time you can get an SQLITE_LOCKED error in the latest code is according to the first bullet above.