All user-defined indexes on source table, including detached and globally detached indexes, are preserved in the destination table. All system-generated indexes are dropped, except those whose constraints are preserved. For more information on constraints, see Moving Tables with Constraints.
By default, if any views exist that depend on source table, MOVE TABLE fails with an error. But if you specify CASCADE mode, then those views are dropped and MOVE TABLE succeeds. Remote views referring to source table are not checked. This functionality is similar to that of the DROP TABLE statement.
Like views, remote synonyms for source table are not checked. Any statement that refers to such synonyms after source table is moved returns an error message, indicating that the specified table does not exist.
Stored procedures referring to source table are not modified. If a stored procedure referencing source table is executed after the table is moved, an error is returned saying the table does not exist.
All triggers associated with the source table are dropped.
If the source table has duplicate tables defined, the duplicate tables are dropped when the table is moved.
All local synonyms of source table are dropped when the table is moved. This includes synonyms created on the views that are dependant on source table.
All column distributions of source table are preserved in the destination table. Entries for source table in the sysdistrib system catalog table are moved. This ensures that the destination table has the same statistics as the source table. For this reason, you do not need to run the UPDATE STATISTICS statement after moving a table.
A source table of the MOVE TABLE statement receives a new tabid as if it were a newly created table. This means that system-defined names of objects that are dependent on source table are also affected. User-defined object names are preserved after the table is moved.
Enterprise Edition Home | Express Edition Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]