Migration procedure
Note: If you already ran the steps to migrate the database from version 3.0.0, Fix Pack 9 to version 3.0.0,
Fix Pack 10, you do not need to run this migration procedure.
Db2
- Create a backup of the database to be migrated so that it can be rolled back if a problem occurs during or after the migration process.
- Start a command window that has Db2® administrative privileges.
- Go to the instdir/ftm/v320/admin/scripts/db2/migration/3.2.0.1_from_3.2.0.0 directory. The files in this directory contain all the database changes since FTM 3.2.0.
- Run one of the following scripts:
Migrate-Win.cmd [Database Name] [Database Schema] [Database User] [Password]
- Main Windows operating system script to update the database.Migrate-Unix.sh [Database Name] [Database Schema] [Database User] [Password]
- Main UNIX script to update the database.
- Optional: The primary key constraint and a separate unique index for the IN_REQ_CORREL table were
given the same name in an earlier release. Because the IN_RCL_PK name was already used by the unique index,
the supporting index was given a system-generated name as shown.
However, this naming issue has no effect on how these constraints and indexes function.Unique Index: - IN_RCL_PK (This name needs to be IN_RCL_UI) Primary Key Constraint: - IN_RCL_PK - Supporting index: System generated name SQLnnnnnnnnnn
Running the migration script partially resolves the issue by renaming the unique index to its proper name, IN_RCL_UI. The supporting index for the primary key constraint cannot be renamed because it has a system-generated name. If you want the primary key constraint and its supporting index to have the same name, drop and re-create it by using these statements:
Depending on the size of the table, these statements might take some time to run.ALTER TABLE IN_REQ_CORREL DROP PRIMARY KEY; ALTER TABLE IN_REQ_CORREL ADD CONSTRAINT IN_RCL_PK PRIMARY KEY(ID);