SQLite: no such table

Result code

SQLITE_ERROR (1)

Product

SQLite library

Versions

SQLite 3.x (examples run on 3.39.2; shell output from 3.50.6)

Category

Missing & Duplicate Objects

Last reviewed

24 October 2026

What it means

The statement names a table that does not exist in the database file this connection opened. Most often the table is fine but the program opened a different, often brand-new and empty, file.

SQLite looks the name up in the schema of the databases the connection has open: main (the file you opened), temp (this connection's temporary tables) and any attached databases. If no table or view has that name, the statement is rejected while it is being prepared, before anything runs. The error is raised for the whole statement, so in a script the statements before it have already run.

The most confusing case is a wrong path. When a program opens a file that does not exist, SQLite normally creates it: in the lab, opening a misspelt path created a 0-byte file and the first query failed with "no such table". Relative paths make this common, because they are resolved from the process's current directory, which differs between your IDE, a web server, a service and a scheduled task. So check which file is open before you look for the table.

Names are not case-sensitive for ASCII letters (CUSTOMERS finds customers; checked on 3.39.2), so case is rarely the cause, but a name containing a non-ASCII letter must match that letter's case exactly. A name with a space or a reserved word must be quoted ("order items"). The error names the schema when the statement did, for example archive.orders, and it reads main.order_log when it comes from a view, trigger or foreign key. Dropping a missing index or view gives the separate messages no such index: ... and no such view: ....

Common causes

• The program opened a different file than you think: a typo or a relative path resolved from another working directory, so SQLite created a new empty database.
• The table was never created on this copy of the database: a migration or setup script did not run, failed half way, or ran against another file.
• The table is in another database file that this connection has not attached, or the statement uses the wrong schema name.
• The table is a TEMP table created on another connection; temporary tables exist only for the connection that created them (connection pools hand you a different one).
• A view, trigger or foreign key still refers to a table that was dropped or renamed.
• A typo in the name, or a name with spaces or a reserved word that needs quoting.

Diagnose it

Read-only These statements only read the schema (sqlite_schema and read-only PRAGMA queries) or your own data. They do not change data, settings or the database file, so they are safe to run first.

PRAGMA database_list;

PRAGMA table_list;  -- SQLite 3.37.0 and later

SELECT type, name, tbl_name
FROM sqlite_schema
WHERE name LIKE '%custom%'  -- part of the name you expect
ORDER BY name;

PRAGMA user_version;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

$db = new PDO('sqlite:' . __DIR__ . '/data/shop.db', null, null, [
    PDO::SQLITE_ATTR_OPEN_FLAGS => PDO::SQLITE_OPEN_READWRITE,  // no SQLITE_OPEN_CREATE
]);

CREATE TABLE IF NOT EXISTS customers (
    id    INTEGER PRIMARY KEY,
    email TEXT UNIQUE
);

ATTACH DATABASE '/srv/app/data/archive.db' AS archive;
SELECT * FROM archive.orders;

CREATE TEMP TABLE cart (id INTEGER PRIMARY KEY, sku TEXT);
INSERT INTO cart (sku) VALUES ('PEN-1');  -- same connection
SELECT * FROM temp.cart;

DROP TRIGGER IF EXISTS trg_orders_log;
CREATE TABLE IF NOT EXISTS order_log (order_id INTEGER, logged_at TEXT);

Examples

A misspelt table name

CREATE TABLE customers (id INTEGER PRIMARY KEY, email TEXT);

SELECT * FROM customer;  -- the table is customers

no such table: customer

A wrong path opens a new, empty database

Lab: the connection opened a path where no database existed. SQLite created a 0-byte file there and the first query failed. The same happens when a relative path is resolved from another working directory.

-- the program opened data/shop-new.db instead of data/shop.db
SELECT * FROM customers;

no such table: customers

A temporary table used from another connection

-- connection A
CREATE TEMP TABLE cart (id INTEGER PRIMARY KEY, sku TEXT);

-- connection B (for example another request from a pool)
SELECT * FROM cart;

no such table: cart

A trigger still writes to a table that was dropped

CREATE TABLE orders (id INTEGER PRIMARY KEY, total REAL);
CREATE TABLE order_log (order_id INTEGER);
CREATE TRIGGER trg_orders_log AFTER INSERT ON orders
BEGIN
    INSERT INTO order_log (order_id) VALUES (new.id);
END;
DROP TABLE order_log;

INSERT INTO orders (total) VALUES (9.99);

no such table: main.order_log

How to prevent it

Configure the database location as an absolute path (or build it from the application's own directory), log the path at start-up, and open existing databases without the create flag, so a wrong path is an error instead of a new empty file. Keep the database outside folders that are recreated on deploy.

Run migrations automatically at start-up and record the schema version (for example in PRAGMA user_version), so code never runs against a file that is behind. When you drop or rename a table, check sqlite_schema for views and triggers that still mention it.

Common questions

Learn more on CodeWithSQL

• Install SQLite (including the command-line shell)
• Try SQLite in the browser playground

Official documentation

• The schema table (sqlite_schema)
• ATTACH DATABASE
• PRAGMA table_list and database_list
• URI filenames (mode=rw and other open options)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQLite 3.39.2 (PHP PDO_SQLITE) and the sqlite3 shell 3.50.6. Messages are the text the SQLite library itself returns (sqlite3_errmsg) for the versions shown.