Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design525637-004
10-33
Execution-Time Name Resolution
Execution-Time Name Resolution
The NonStop SQL/MP product allows you to dynamically resolve the names of SQL
objects referenced in SQL statements as the program is executing. This feature is
useful, for example, when executing the same transaction code against different SQL
tables.
Without Late Name Resolution
To show how execution-time name resolution enhances availability, let’s first consider
how name resolution works without this feature. You have the following three choices:
Use dynamic SQL.
This approach lets you dynamically resolve names but usually executes with lower
performance and is more complex to program than static SQL.
Restart the application to allow automatic recompilation of the execution plans
affected by the change and establish the new bindings.
This approach executes less efficiently than the original program because of the
need to automatically recompile every time the program is executed.
Compile the program with SQL.
This approach produces efficient code but requires that the application be brought
down for recompilation.
Therefore, without dynamic or execution-time name resolution, you have a choice
between downtime or a less efficient program if you want to bind alternate names.
With Late Name Resolution
Using execution-time name resolution, you bind the names of objects as the program
executes. Execution-time name resolution is selected by the CONTROL QUERY BIND
NAMES compiler directive as follows:
CONTROL QUERY BIND NAMES AT EXECUTION
Figure 10-5 on page 10-34 shows an example of how execution-time name resolution
might work to change the database that a program accesses.
The program is first developed on a development system with the CONTROL QUERY
BIND NAMES directive set for execution-time name resolution. SQL tables must be
accessed by DEFINEs to enable dynamic name change. After moving the application
to the production system, the DEFINE is set to refer to a given table. The DEFINE
referred to is subsequently dynamically changed by the program for each transaction
that it executes.
To avoid automatic recompilations every time the program accesses a new table, the
similarity check is turned on for the table (using ALTER TABLE) and for the program by
compiling with SQL, using the CHECK INOPERABLE PLANS directive.