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.

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):

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:

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.

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.

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.

Anonymous adds: The following item (formerly numbered 4) is
completely wrong. The person who added it is confusing the
SQLITE_BUSY error with SQLITE_LOCKED. If an SQLITE_LOCKED error had
been returned, the error message text would have been "database
table is locked".

Anonymous continues: Since the item is wrong and misleading, I am
going to delete it. I'm adding this text here for now so that people
looking through this page's history will know why it was deleted.

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:

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.