SQL/MX 3.2 Programming Manual for C and COBOL (H06.25+, J06.14+)

Name Resolution, Similarity Checks, and Automatic
Recompilation
HP NonStop SQL/MX Release 3.2 Programming Manual for C and COBOL—663854-002
8-10
Similarity Check
recompile the SQL plan. For more information, see Automatic Recompilation on
page 8-18.
Causes of a Similarity Check
When enabled, a similarity check occurs for these reasons:

Changed DEFINEs or PROTOTYPE Host Variables on page 8-10

Failed Timestamp Check on page 8-10
Similarity checks are performed regardless of the method chosen to refer to tables in
the source code: hard-coded Guardian or logical names, class map DEFINEs, or
PROTOTYPE host variables. However, similarity checks for views are performed only
when views are referred using logical names or PROTOTYPE host variables. For more
information, see Name Resolution on page 8-1.
Changed DEFINEs or PROTOTYPE Host Variables
The SQL/MX executor performs a similarity check if a statement that was compiled for
one table or view, specified by either a class map DEFINE or a PROTOTYPE host
variable, will now be executed to process a different table or view specified by a new
DEFINE or host variable value, respectively. For more information, see Late Name
Resolution on page 8-6 and Late Name Resolution for Tables Referred by the View on
page 8-7.
If the value of a DEFINE or a PROTOTYPE host variable changes, the SQL/MX
executor initiates a similarity check, comparing the compile-time table or view to the
run-time table or view, respectively, to determine if the query execution plan is still
operable. See Similarity Check Criteria on page 8-11 and Similarity Check Criteria for a
View on page 8-13.
Failed Timestamp Check
The SQL/MX executor performs a similarity check if a timestamp check fails, which
occurs if the table’s or view’s redefinition timestamp has changed since the referencing
statement was compiled. The SQL/MX executor performs a timestamp check for each
table or view referenced in an SQL statement at table or view open time (the first time
the table or view is opened). The timestamp check ensures that the current execution
plan of an SQL statement uses a valid definition of each table or view.
After the SQL/MX compiler has prepared the query execution plan of a statement,
changes to the tables or views that the plan processes can occur. For example, an
index can be added or removed, or a partition added. Changes of this nature can
render the plan inoperable. These types of changes to a table also change the
redefinition timestamp of the table.
Each table or view contains a redefinition timestamp in its file label. At compile time,
the timestamp of each table or view accessed by an SQL statement is stored with the
compiled plan of the statement in a module. When executing a plan, the SQL/MX
executor compares the current timestamp in the table’s or view’s file label with the
compile-time timestamp of the same table or view in the query execution plan. If the