Skip to content

Open Statements

A database file that SQLite Expert is holding is a database file another program may not be able to write to. Tools → Open Statements shows what is being held, by which connection, and for how long.

This matters because of how SQLite works rather than anything peculiar to this program. A statement that has been stepped and not yet finished keeps a read transaction open, and in the default rollback-journal mode that is a shared lock on the file: other applications can still read the database, but none of them can commit a write until the lock goes. A grid showing a table keeps such a cursor between reads, which is what makes it worth being able to see.

The busy indicator

Each database in the tree carries a small indicator. Red means the file is being held at that moment; green means it is free and another application can write to it.

It is drawn before the work starts rather than after it finishes, so it is already red when a long read begins. Two things it cannot do: a hold that begins and ends in a fraction of a second may never be shown at all, and while the program is genuinely busy inside SQLite nothing on screen can be repainted — so the indicator is reliable for holds that last, which are the ones that affect anybody else.

The window

Open Statements Open Statements

The line along the top is the answer in plain words — 1 open, none holding. Another application can read and write every open database — so the usual question can be settled without reading the grid at all.

Below it is one row per statement: the database it belongs to, whether it is Holding the file, how long it has been held For, and the Statement itself.

Show all statements decides how much is listed. With it off — the default — the window shows what is holding the file, and anything that has held it long enough to be worth knowing about. With it on, every prepared statement on every connection is listed, including SQLite's own: a virtual table module keeps statements of its own for as long as the database is open, and an R-Tree table keeps several per table. Those hold nothing and cannot be closed, which is why they are hidden unless asked for.

The window updates itself while it is open, and its position and the state of Show all are remembered between sessions.

Note

Nothing here needs to be acted on. A red indicator during a large read is the program working, not a fault. It is worth looking at when another application reports that the database is locked, and you want to know what is holding it.

See also: Cancelling the execution of a long-running SQL script