sqlite - Database Is Locked

Not logged in

• Honeypot
• Browse
• Home
• Login
• Reports
• Search
• Ticket
• Timeline
• Wiki

• Attach
• Contents
• Diff
• Edit
• History
• Text

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.

   • As of check-in [3902] (2007-05-02 after version 3.3.17) this is now allowed for CREATE statement.

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.

4. I found out that you can get the SQLITE_LOCKED error when trying a COMMIT after a change, when another connection has a SELECT open. Example:

Prepare some table, e.g.

  create table t(x integer);
  insert into t values(1);
  insert into t values(2);

now use 2 connections:

  Connection 1: begin transaction;
  Connection 2: begin transaction;
  Connection 1: select * from t;
  Connection 2: select * from t;
  Connection 1: delete from t where x = 1;
  Connection 1: commit;

now we see 'database is locked'!

Only after giving another 'Commit' or 'Rollback' on connection 2, the 'Commit' of connection 1 can be successfully repeated, e.g.

  Connection 2: commit;
  Connection 1: commit;

This is a bit unusual, as most other DB systems have no problem running a read-only query on committed values while other transactions are active.

And as one can see, in contrary to what others have written earlier on this page, it is not necessary to use two incompatible things within the same database connection. This works with two independant connections. It plays no role whether these connections belong to the same process or two different processes.