Execution Elements

Previous Next

See Also

The Execution Elements tab page on the Test Profiles window shows information about the SQL statements that are performed within a profile:




The sequence number of this element.

Executed SQL

If this field is set to Yes, the element is en executed SQL Statement.

If this field is set to No, the element is a grouping element.


Shows the ID of the parent element of this element.

Manipulation Seqno

The sequence number of the manipulation that has triggered this SQL.

If this field is empty, the SQL statement is not triggered by a manipulation.

For example, when an INSERT constraint is triggered by a manipulation, the SELECT_FOR_INSERT statement of the constraint will be connected to the manipulation that triggered the constraint. When the SELECT_FOR_INSERT statement retrieves a record and is ready to perform the insert, it will fire a uniqueness check and then the actual insert. The check and insert will both then have a new manipulation sequence number.

Group Time

For grouping elments, this field displays the time required to perform the group of elements.


The time used to perform this SQL statement.

Time 0 means that USoft BenchMark cannot measure the time.

% Total SQL Time

The percentage of the Total SQL Time needed to perform this SQL statement.

Rows Processed

The number of records involved in this SQL statement


"Yes" means that the SQL statement is processed on the client computer.

"No" means that the SQL statement is sent to the database server.

Constraint Execution ID

Every time that the Rules Engine starts to check if a constraint needs to be fired or not, it will create a new 'constraint exe ID'. If that constraint then actally fires one or more SQL statements, those SQL statements will all then be allocated this constraint execution ID. In this manner, different SQL statements can be located and matched. For example constraint key queries can me matched with their corresponding constraint tests (if any). Because not every checked constraint will result in a SQL statement (the Engine can pre-evaluate constraints as well) it is likely that there will be 'gaps' between the constraint execution IDs. Furthermore, the ID is not bound to a single profile: a constraint key query recorded by profile 1 and the corresponding constraint-test recorded by profile 2 will have the same constraint execution ID. The constraint execution ID is not reset in a new profile.

Source Type

The area of USoft Developer that this SQL statement is related to.


The name of the domain constraint, the constraint, or the relationship that causes the execution of this SQL statement.


The internal reason why this SQL statement is executed.

See also: "Reasons for SQL Statements"

SQL Statement

The SQL Statement as the Rules Engine processes it internally.

The Rules Engine attempts to execute this SQL statement using information that is already available on the client computer.

RDBMS SQL Statement

The SQL Statement as it is sent to the database, to be processed by the RDBMS.

If it turns out that server data is required, the Rules Engine builds this RDBMS SQL statement.

Initial SQL Statement

The Rules Engine occasionally has to evaluate a SQL statement which needs to be split up into several statements because it contain invokes or references to table components as well as database tables. The profiler will record and show these 'initial' statements, so you can see how the engine will perform the splitting of the statement. In this manner performance problems can be adressed by changing the SQL statement in such a way that the Rules Engine will change the way it splits up the statement . These execution elements are displayed as group element (the Executed-SQL field is set to No).

For more information on increasing performance, see the Rules Engine help.

Source Details

This field contains detailed information about the execution element. For example, when a row event is fired by a decision, the details of the rowevent (table name and primary key values) are displayed.