What causes "Error querying database: {}" in tursodatabase/turso?

Read the inner error text — it is the engine's real diagnosis (no such table, I/O error, malformed image, ...).

Error querying database: {}

Error message

Error querying database: {}

What it means

This is the shared handle_row helper (cli/app.rs:1707) behind the CLI's dot commands (.tables, .indexes, .databases, schema helpers). When conn.query(sql) itself fails — the statement could not even be prepared or started — the error is wrapped as 'Error querying database: {err}'. Busy and Interrupt get dedicated handling; every other failure funnels here.

Source

Thrown at cli/app.rs:1729

        match self.conn.query(sql) {
            Ok(Some(ref mut rows)) => {
                let res = rows.run_with_row_callback(handler);
                match res {
                    Ok(_) => {}
                    Err(LimboError::Busy) => {
                        let _ = self.writeln("database is busy");
                    }
                    Err(LimboError::Interrupt) => {
                        let _ = self.writeln(LimboError::Interrupt.to_string());
                    }
                    Err(err) => return Err(anyhow!(err)),
                }
            }
            Ok(None) => {
                let _ = self.writeln("No results returned from the query.");
            }
            Err(err) => {
                return Err(anyhow::anyhow!("Error querying database: {}", err));
            }
        }
        Ok(())
    }

    fn display_databases(&mut self) -> anyhow::Result<()> {
        let sql = "PRAGMA database_list";
        let conn = self.conn.clone();
        let mut databases = Vec::new();
        self.handle_row(sql, |row| {
            if let (
                Ok(Value::Numeric(Numeric::Integer(seq))),
                Ok(Value::Text(name)),
                Ok(file_value),
            ) = (
                row.get::<&Value>(0),
                row.get::<&Value>(1),
                row.get::<&Value>(2),

View on GitHub (pinned to bad083fafb)

Solutions

Read the inner error text — it is the engine's real diagnosis (no such table, I/O error, malformed image, ...).
Fix the referenced object names and confirm attachments with '.databases'.
Run PRAGMA integrity_check; to rule out corruption.
Reopen the database in a fresh session if the file was touched externally.

Defensive patterns

Strategy: try-catch

Validate before calling

-- Run the dot command's backing SQL directly first to get the raw engine error:
SELECT name FROM sqlite_schema WHERE type='table';  -- what .tables runs

Try / catch

// Branch on the inner engine error carried by the wrapper:
if let Err(e) = shell.handle_dot_command(cmd) {
    let msg = e.to_string();
    if msg.contains("Error querying database") {
        let inner = msg.split(": ").last().unwrap_or(&msg);
        // handle: unknown object name / io error / malformed database
    }
}

Prevention

Validate object names and attachments ('.databases') before dot commands that take 'db.' prefixes.
Run suspicious SQL directly in the REPL — the raw engine error is more actionable than the wrapper.

When it happens

Trigger: Any dot command whose backing SQL fails to prepare: referencing 'db.table' where 'db' is not attached, a corrupted catalog page, I/O errors reading the file, or SQL syntax the engine rejects.

Common situations: Typos in dot-command arguments; sessions left open after the file was rotated or unmounted; databases corrupted by concurrent writers; engine/parser gaps hit by generated SQL.

Related errors

AI-assisted analysis of tursodatabase/turso@bad083fafb (2026-08-16). Data as JSON: /api/errors/b6b6fd8d4eb09d34. Report an issue: GitHub.