**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 {link: tclsqlite.html 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
{link: /capi3ref.html#sqlite3_open 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.