Field
|
Meaning
|
ID
|
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.
|
Parent
|
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.
|
Time
|
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
|
Optimized
|
"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.
|
Source
|
The name of the domain constraint, the constraint, or the
relationship that causes the execution of this SQL statement.
|
Reason
|
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.
|