SQL/MX 2.x Database and Application Migration Guide (G06.23+, H06.04+, J06.03+)

Version Management and Interoperability
HP NonStop SQL/MX Database and Application Migration Guide—540435-005
2-16
Reasons for Upgrading All Nodes to the Same
Version of SQL/MX Release 2.x
Reasons for Upgrading All Nodes to the Same Version of
SQL/MX Release 2.x
On SQL/MX Release 2.0, 2.1, and 2.2 nodes, compiling an SQL/MX application that
refers to database objects on nodes that have earlier versions of SQL/MX Release 2.x
might produce query execution plans that do not have the performance enhancements
of the latest version of SQL/MX Release 2.x. For optimal performance, consider
upgrading all referenced SQL/MX Release 2.x nodes to the latest version of SQL/MX
Release 2.x.
Falling Back a Local SQL/MX Node
After you fall back to an earlier version of SQL/MX Release 2.x, you must recompile all
user modules that you compiled using the newer version of SQL/MX Release 2.x. For
example, after you fall back from SQL/MX Release 2.2 to SQL/MX Release 2.1 or 2.0,
you must recompile all version 1600 user modules. Version 1600 modules from
SQL/MX Release 2.2 cannot run on an SQL/MX Release 2.1 node, which executes
version 1400 plans, and they cannot run on an SQL/MX Release 2.0 node, which
executes version 1200 plans. Version 1600 modules fail to execute on the downgraded
node and return errors because their module versions are incompatible with the current
MXV.
The same is true when falling back from SQL/MX Release 2.1 to SQL/MX Release 2.0.
After you fall back from SQL/MX Release 2.1 to SQL/MX Release 2.0, you must
recompile all version 1400 user modules. Version 1400 modules from SQL/MX
Release 2.1 cannot run on an SQL/MX Release 2.0 node, which executes version
1200 plans.
Falling Back a Remote SQL/MX Node Referenced by an
Application on an SQL/MX Release 2.0, 2.1, or 2.2 Node
After you fall back a remote node to an earlier version of SQL/MX Release 2.x, you
must recompile all user modules that refer to the downgraded node. For example,
suppose that you compile embedded SQL/MX applications on an SQL/MX Release 2.2
or 2.1 node and those applications query database objects on remote nodes. If you fall
back a remote SQL/MX Release 2.x node to an MXV that is lower than the compiled
plans but higher than 800, the SQL statements that refer to database objects on the
downgraded node fail to execute and return errors.