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

  1. 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.
  2. Start a command window that has Db2® administrative privileges.
  3. 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.
  4. 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.
  5. 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.
    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
    However, this naming issue has no effect on how these constraints and indexes function.
    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:
    ALTER TABLE IN_REQ_CORREL DROP PRIMARY KEY;
    
    ALTER TABLE IN_REQ_CORREL ADD CONSTRAINT IN_RCL_PK PRIMARY KEY(ID);
    Depending on the size of the table, these statements might take some time to run.