Skip to main content
Version: Current

Execute Non-Query

Description​

The Execute Non-Query activity executes a SQL command that does not return a result set against a connected database.

It is intended for statements such as INSERT, UPDATE, DELETE, and schema (DDL) commands (CREATE, ALTER, DROP). It exposes the affected-row count reported by the database provider.

tip

Use Execute Non-Query when the statement modifies data or schema and you need the affected-row count.

For retrieving rows with a custom SELECT (including joins, subqueries, aggregations, or CTEs), use the Execute Query activity.

Prerequisites​

  • Create and test a database connection in the AI Command Center.
  • Ensure the database is reachable from the environment that runs the workflow.
  • Ensure the connection account has permission to execute the intended SQL operations, including schema changes when applicable.
  • Confirm the database object names and SQL syntax for the selected database engine.

Common Capabilities​

Process Data Support​

info

This activity supports dynamic configuration using variables from the Process Data drawer.

You can bind values from Model Data, Form Data, System Data, Enterprise Variables, and Activity Outputs.

Learn more → Using Process Data

Design-Time Configuration​

The following properties define how the activity connects to the database and executes the SQL command.

Connection Type​

Specifies the database engine (for example, SQL Server, Oracle, MySQL, PostgreSQL). Selecting the correct type ensures compatibility with the target database.

Connection Name​

Select a preconfigured database connection that matches Connection Type and points to the intended database. The connection defines the server, credentials, and security settings.

SQL​

Specifies the SQL command to execute.

The statement must be valid for the selected database engine. Typical examples include:

  • Data changes: INSERT, UPDATE, DELETE
  • Schema changes: CREATE, ALTER, DROP
note

The Execute Non-Query activity does not return a result set. Use Execute Query when the statement returns rows.

Timeout​

Specifies the maximum time (in seconds) that the activity will wait for the command to complete.

The default value is 600 seconds.

Outputs​

Records Affected​

Returns the number of records affected by the command for statements such as INSERT, UPDATE, and DELETE.

The affected-row count depends on the database provider and command. For commands that do not report a row count, including many structural (DDL) commands, the value may be -1. Do not interpret -1 as an activity failure or as a count of modified rows. Use On Error to handle execution failures.

This value can be used for:

  • Validation
  • Reporting
  • Conditional workflow logic

Execution Control and Error Handling​

Wait All Incoming​

Execution Control

Controls how this activity behaves when multiple incoming execution paths converge.

Determines whether the activity executes when:

  • any incoming path completes, or
  • all relevant paths have completed before execution

Learn more → Execution Control

On Error​

Error Handling Strategy

Defines how the workflow behaves if this activity encounters a runtime error.

Supported strategies include Fault, Continue, Suspend, and Retry. Select Inherit to use the workflow-level policy.

Learn more → Error Handling

Example: Update an Order Status​

This example uses a SQL Server table named dbo.Orders with an integer OrderId column and a text Status column.

  1. Add Execute Non-Query to the workflow.

  2. Set Connection Type to SQL Server and select the connection for the database containing dbo.Orders.

  3. Set SQL to the following statement:

    UPDATE dbo.Orders
    SET Status = 'Processed'
    WHERE OrderId = 1001;

  4. Keep Timeout at 600 seconds or adjust it for the expected execution time.

  5. Configure On Error and run the workflow against test data.

  6. Use Records Affected in a subsequent condition to check the reported count. If OrderId is unique and the provider reports row counts, an existing order normally produces 1; no matching order normally produces 0.

Adapt the table, column names, and SQL syntax to your database. A successful command that matches no rows does not necessarily indicate a workflow error.

Usage Notes​

  • Review the WHERE clause of an UPDATE or DELETE statement. Omitting it can modify every row in the target table.
  • Schema commands require appropriate database permissions and do not produce a result table.
  • Binding workflow data to SQL does not by itself establish SQL parameterization. Avoid concatenating untrusted values into SQL. For operations with mapped input arguments, consider Execute Stored Procedure.
  • Before enabling Retry, consider whether executing the command again could duplicate an insert or repeat a data change. After a timeout or connection failure, verify the database state before repeating a write.
  • For visual column mapping, use Insert Record or Update Record. Use Delete Records to delete records through filter configuration.
Help improve this page