tursodatabase/turso · error · SQLException

Exception while resetting statement

Error message

Exception while resetting statement

What it means

Thrown when the native reset call returns -1. The native implementation returns -1 either when the statement pointer cannot be resolved (closed/finalized statement) or when stmt.reset() itself errors. Reset is meant to clear bindings and results of a live statement so it can be re-executed; it cannot revive a closed one.

Source

Thrown at bindings/java/src/main/java/tech/turso/core/TursoStatement.java:297

   *
   * @throws SQLException If a database access error occurs
   */
  public int parameterCount() throws SQLException {
    final int result = parameterCount(statementPointer);
    if (result == -1) {
      throw new SQLException("Exception while retrieving parameter count");
    }

    return result;
  }

  private native int parameterCount(long statementPointer) throws SQLException;

  /** Resets this statement so it's ready for re-execution */
  public void reset() throws SQLException {
    final int result = reset(statementPointer);
    if (result == -1) {
      throw new SQLException("Exception while resetting statement");
    }
    this.resultSet = TursoResultSet.of(this);
  }

  private native int reset(long statementPointer) throws SQLException;

  /**
   * Checks if the statement is closed.
   *
   * @return true if the statement is closed, false otherwise.
   */
  public boolean isClosed() {
    return closed;
  }

  @Override
  public String toString() {
    return ("tursoStatement{"

View on GitHub (pinned to bad083fafb)

Solutions

1. Check isClosed() before reset() and re-prepare the statement if closed.
2. In error paths, drop the statement and prepare a fresh one instead of resetting the old handle.
3. Ensure the connection is still open before resetting.
4. Keep reset() inside the same try block that owns the statement's execution loop.

Example fix

// before
stmt.close();
stmt.reset(); // throws: cannot reset a closed statement

// after
if (!stmt.isClosed()) {
    stmt.reset();
} else {
    stmt = conn.prepare(sql); // re-prepare instead of resetting a dead handle
}

if (stmt.isClosed()) {
    stmt = conn.prepare(sql); // fresh statement instead of resetting a dead one
} else {
    stmt.reset();
}

try {
    stmt.reset();
} catch (SQLException e) {
    // handle is stale or reset failed: discard and re-prepare
    stmt = conn.prepare(sql);
}

When it happens

Trigger: stmt.reset() after stmt.close(); reset after the connection was closed; reset racing with another thread closing the statement; native reset erroring on an aborted/interrupted statement.

Common situations: Batch loops that reset a statement per iteration but whose error handler closed the statement on a previous failure; connection pools that reset statements on return after already closing them; timeout/abort paths that invalidate the statement before the retry loop resets it.

Related errors

• Exception while retrieving total number of changes
• Exception while retrieving number of changes
• Exception while retrieving parameter count
• database connection closed
• Failed to convert ${sql} into bytes

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