apache/shardingsphere · error · SQLFeatureNotSupportedException

moveToCurrentRow

Error message

moveToCurrentRow

What it means

moveToCurrentRow() is final in AbstractUnsupportedOperationResultSet and throws SQLFeatureNotSupportedException unconditionally. It only has meaning after moveToInsertRow() on an updatable cursor, and the sharding ResultSet supports neither, so the call is rejected outright.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationResultSet.java:125

    
    @Override
    public final void refreshRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("refreshRow");
    }
    
    @Override
    public final void cancelRowUpdates() throws SQLException {
        throw new SQLFeatureNotSupportedException("cancelRowUpdates");
    }
    
    @Override
    public final void moveToInsertRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToInsertRow");
    }
    
    @Override
    public final void moveToCurrentRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToCurrentRow");
    }
    
    @Override
    public final boolean rowInserted() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowInserted");
    }
    
    @Override
    public final boolean rowUpdated() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowUpdated");
    }
    
    @Override
    public final boolean rowDeleted() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowDeleted");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Remove the whole cursor-insert block and replace it with plain INSERT SQL.
  2. Re-point the editing component at the physical datasource connection if cursor semantics are non-negotiable.
  3. Ensure Statement is created with ResultSet.CONCUR_READ_ONLY so frameworks never enter the updatable-cursor code path.

Example fix

// before
rs.insertRow();
rs.moveToCurrentRow(); // throws

// after
// after executing the INSERT PreparedStatement, simply continue using the query ResultSet
// no moveToCurrentRow call exists
Defensive patterns

Strategy: try-catch

Validate before calling

// only reachable after moveToInsertRow; guard that call instead
boolean canUseInsertRow = rs.getConcurrency() != ResultSet.CONCUR_READ_ONLY;

Try / catch

try {
    rs.moveToCurrentRow();
} catch (SQLFeatureNotSupportedException e) {
    // no cursor-insert mode was ever entered; nothing to restore
}

Prevention

When it happens

Trigger: Calling ResultSet.moveToCurrentRow() on a sharding ResultSet, usually as part of a cursor-insert/edit flow (after insertRow or when leaving the insert row) inside ORM or UI grid code.

Common situations: CRUD form frameworks that pair moveToInsertRow/insertRow/moveToCurrentRow; code copied from driver documentation for updatable ResultSets (MySQL, Oracle, DB2) and run against the sharding URL.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/fb60ebf34eecaa65. Report an issue: GitHub.