SQL/MP Version Management Guide

Database Versions
Compaq NonStop™ SQL/MP Version Management Guide—429833-001
3-16
Object-Version Dependencies
•
All partitions of a given table are considered to be a single object, and all have the
same version number. For example, if one partition of a table has the version
number 300, all partitions of that table are version 300.
•
The version of a protection or shorthand view depends on the versions of the tables
or views on which the view is based. The version of a view can be the same as (or
newer than) the newest version of its underlying tables or views, but cannot be
older. For example, a version 300 view can be based on a version 2 or version 300
table, but not on a table with a version number newer than 300.
•
The version of a table depends on the version of its indexes. The version of a table
can be the same as (or newer than) the version of its index, but it cannot be older.
For example, a base table might use version 300 features, making it a version 300
table, and still have a version 2 index. However, a table cannot have an index with a
version number newer than 300.
•
The version of a table depends on the versions of features used by any constraint on
the table. The version of a table can be the same as (or newer than) the newest
version of any of its constraint features, but it cannot be older. For example, a table
might use version 300 features, making it a version 300 table, and have a constraint
with version 2 features. However, a table cannot have a constraint with any features
newer than version 300.
•
The version of a table, index, or view depends on the version of its referenced
collations. The version of a table, index, or view can be the same as (or newer than)
the version of any of its collations, but it cannot be older. For example, a version
300 view might refer to a version 300 collation, but not to a collation with a version
newer than 300.
Changing Object Versions
You change the version of an SQL object by changing features of the object. When you
add features that raise the object’s version, you raise also the version of any object
whose version number depends on the version of the changed object. Such automatic
upgrading of object versions can alter the versions of other objects throughout a
database.
Automatic upgrading of versions ensures that object versions are compatible. In a
network, however, automatic upgrading can cause problems for existing applications
running on older nodes if they access objects on remote nodes whose versions are
upgraded. For more information about managing object versions in a network, see
Section 6, Mixed Version Networks
.
Any DDL operation or utility operation can result in the automatic upgrading of objects
whose version depends on the version of a specified object. In particular, to guard
against inadvertently changing the version of an object, you must understand how the
DROP and ALTER commands and the CLEANUP utility affect object version. The
DROP and ALTER commands and the CLEANUP utility are described under DROP
and Object Versions on page 3-17, ALTER and Object Versions on page 3-17, and
CLEANUP Utility and Object Versions on page 3-18.
For more information about the effects of object version changes on programs, see
Section 5, Program Versions
.