pentaho/pentaho-kettle · error · KettleStepException

ExecSQL.Log.ErrorInStep

ExecSQL.Log.ErrorInStep

Error message

ExecSQL.Log.ErrorInStep

What it means

Generic error wrapper thrown by ExecSQL.processRow when the step's work (executing SQL per row) throws a KettleException and the step is NOT configured with error handling. If error handling is enabled the exception is instead routed to the error row stream; without it, it becomes a KettleStepException with message 'ExecSQL.Log.ErrorInStep' and the SQL failure as cause.

Solutions

1. Read the wrapped cause for the actual SQL/database error
2. Fix the SQL statement or database state indicated by the cause
3. Attach an error handling step (error hop) to route failing rows instead of aborting
4. Verify the database connection defined in the ExecSQL step (test + credentials)
5. Enable 'execute for each row' / parameter binding correctness to avoid SQL injection/format errors

Example fix

// before: no error handling -> step aborts on SQL failure
// after (design-time fix): attach an error hop
execSqlStep.getStepMeta().setDoingErrorHandling(true);
execSqlStep.addErrorHop(targetErrorLogStep);
// rows failing SQL go to the error stream instead of throwing

// design-time: verify SQL and connection
if (execSqlMeta.getDatabaseMeta() == null) throw new IllegalStateException("ExecSQL connection missing");
// test the SQL manually against the target DB before running the transformation

try { trans.execute(null); trans.waitUntilFinished(); if (trans.getErrors() > 0) { /* read step log for ExecSQL.Log.ErrorInStep cause */ } } catch (KettleException e) { logError("ExecSQL failed: " + e.getCause()); }

When it happens

Trigger: Any SQL execution failure during processRow — invalid SQL statement, database connection failure, constraint violation, missing table — combined with no error-handling step attached to ExecSQL.

Common situations: SQL syntax errors after editing the SQL template; database credentials expired; target table dropped; deadlock or timeout on large executions; forgetting to attach an error hop so failures abort the transformation.

Understand the failure class

Background: "query failed", "%w: SQL error" — wrapped database query errors in Go libraries explained — this error's family across 3 libraries.

Related errors

• AddSequence.Exception.ErrorReadingSequence
• TableExists.Log.ErrorInStep
• TableInput.Exception.NoParametersFound
• AbstractFileErrorHandler.Exception.CouldNotCreateFileErrorHandlerForFile
• AddSequence.Exception.NoSpecifiedMethod

AI-assisted analysis of pentaho/pentaho-kettle@f3058517a1 (2026-09-13). Data as JSON: /api/errors/a9d176f03e930630. Report an issue: GitHub.

Appendix: source

Thrown at engine/src/main/java/org/pentaho/di/trans/steps/sql/ExecSQL.java:229

      row = RowDataUtil.addRowData( row, getInputRowMeta().size(), add.getData() );

      if ( !data.db.isAutoCommit() ) {
        data.db.commit();
      }

      putRow( data.outputRowMeta, row ); // send it out!

      if ( checkFeedback( getLinesWritten() ) ) {
        if ( log.isBasic() ) {
          logBasic( BaseMessages.getString( PKG, "ExecSQL.Log.LineNumber" ) + getLinesWritten() );
        }
      }
    } catch ( KettleException e ) {
      if ( getStepMeta().isDoingErrorHandling() ) {
        sendToErrorRow = true;
        errorMessage = e.toString();
      } else {
        throw new KettleStepException( BaseMessages.getString( PKG, "ExecSQL.Log.ErrorInStep" ), e );
      }

      if ( sendToErrorRow ) {
        // Simply add this row to the error row
        putError( getInputRowMeta(), row, 1, errorMessage, null, "ExecSQL001" );
      }
    }
    return true;
  }

  @Override
  public void dispose( StepMetaInterface smi, StepDataInterface sdi ) {
    meta = (ExecSQLMeta) smi;
    data = (ExecSQLData) sdi;

    if ( log.isBasic() ) {
      logBasic( BaseMessages.getString( PKG, "ExecSQL.Log.FinishingReadingQuery" ) );
    }

View on GitHub (pinned to f3058517a1)