SQL/MP Reference Manual

HP NonStop SQL/MP Reference Manual523352-013
A-38
Considerations—ALTER TABLE
Only one DDL statement can operate on a given SQL object (or partition of an SQL
object) at a time. An error occurs if you attempt to execute an ALTER TABLE
statement while another process is executing a DDL operation on the same object.
The specific error depends on the DDL operation involved and the phase of the
operation at which the conflict occurs. For more information, see DDL (Data
Definition Language) Statements on page D-20.
Additional authorization and access requirements that exist for some ALTER
TABLE operations are described in the coming subsections.
Renaming tables
To rename a table, you must have authority to read and write to the catalogs
that describe the views, indexes, programs, and collations associated with the
table, in addition to the catalog that describes the table.
Renaming a table does not invalidate any programs dependent on the table.
Existing OPENs of the renamed table are redirected to the new name, and the
corresponding programs continue to run until the new OPENs are required.
The non-running programs dependent on the table might experience
subsequent errors unless:
A replacement copy of the original table name is created, or
DEFINEs are re-directed to the renamed table. SQL re-compilation might
be necessary or advisable in some situations.
You cannot rename a table within a user-defined transaction.
Altering file attributes for tables
To alter security attributes for a table, the table and any indexes and protection
views defined on the table must be accessible.
Changing either the SECURE or OWNER attribute of a table can affect
processes using the table when the change occurs. ALTER TABLE closes the
table to make the change. Other SQL processes using the table attempt to
reopen it after the change, but the new attribute values can prevent such
processes from doing so.
Changing the OWNER for a table automatically changes the OWNER of
indexes and protection views defined on the table.
Changing the SECURE attribute for a table automatically changes the
SECURE attribute of indexes defined on the table. In addition, changing the
SECURE attribute for a table automatically changes the SECURE attribute of
protection views defined on the table if such a change is necessary to meet
these requirements:
Purge authority for the protection view must include the users authorized to
purge the underlying table.