Click the Generate script button to generate the Create_IDXs.sql script with which all indexes will be created. The script is automatically saved for later use.

Run the Generate_Drop_IDXs.sql script shown on the MS SQL database.

The SEPA/IBAN conversion already performed during the test migration has to be undone. In Sybase, new data could have been added to tables containing bank account information. These new data should be properly converted as well. If you undo the SEPA/IBAN migration, applying the latest database patch will migrate all data.

Click the Run script button to run the Undo_SEPA_IBAN.sql script.

1. Start the SSMA tool and open the migration project created earlier.
2. In the Sybase section of the SSMA tool, select Tables. All tables are now selected.
3. Right-click Tables and choose Migrate Data.

   

4. Log onto the ASE server.

You now have to wait for about four to eight hours.

Following the data migration, create a report containing the results in the SSMA tool:

• Click the Save Report button and enter a file name and file location.

Click the Run button to check the data migration. For every table, the number of records in the Sybase database is compared with the number of records in the MS SQL database. Any differences are logged. A list of all tables and the number of records are saved in the TablesRecordCount.log file.

If any of the tables have not been migrated correctly, you can use the scripts in the Data_Repair folder to:

• disable the triggers and foreign keys (scripts 01 and 02)
• clear the failed tables (script 03)
• re-enable the foreign keys and triggers (scripts 04 and 05). The foreign keys and triggers must be enabled for the SSMA tool to work.

After this, use the SSMA tool to transfer the contents of the failed tables only.

Warning: Do not forget to modify the WHERE clause in script 03. Otherwise, all tables will be cleared.

Run the Save_ASE_Config.sql script.

Run the SaveIdentityTables.sql script that was generated in a previous step.

Run the Restore_TestConfig.sql script. The script may report the error “SQL Error: SQL Error Code: 50000 Not all foreign key constraints are trusted”. You can ignore this error for now.

Run the T_ProjectLineCostBudgetLog_After.sql script shown on the MS SQL database.

1. Click the Generate script button to generate the script to reintroduce identity columns into custom tables.
2. Click the Run script 1 button to run the generated script on the MS SQL Server database.
3. Click the Run script 2 button to re-create triggers on the custom tables with identity columns.

The Create_IDXs.sql script that was created earlier is shown. Run this script.

1. Navigate to the folder containing the MS SQL Server database patch.
2. Read the Update Guide and follow the instructions to apply the latest patch to the MS SQL Server database.

   For large databases, set the transaction log to ´Unrestricted File Growth´ and check the Enable Autogrowth checkbox: right-click on Database, Properties, Files, Log file.

   

   After applying the patch, you can shrink the log again.

This step will repair the reports, permissions and scripts that depend on obsolete reports, program codes and scripts.

• Run the scripts Delete_Obsolete_ProgramParams.sql and Delete_Obsolete_Permissions.sql.

In the tables below, delete all references to obsolete reports from the listed columns.

As a consequence of the unicode conversion for version 4.5, some user passwords will be corrupted after the data migration of the Isah database. You can use the procedure below to restore these passwords.

After the test migration, prompt all users to log into Isah. If users cannot log in, reset their passwords to what it used to be in version 4.0.

To log into Isah without an Isah password

1. Start Isah. The Isah Login form will be displayed.
2. In the Administration field, select the database to which you want to log in.
3. In the Name field, type ‘sa’, followed by a right angle bracket (>) and then type the Isah user name whose password was lost. ‘sa’ stands for ‘System Administrator’ and concerns a MS SQL Server account that can access every database on the MS SQL server.

   Example

   Database: ProductionDB

   Name: sa>John

4. In the Password field, type the password for the ‘sa’ user.
5. Click OK to log into Isah.
6. Open the General Settings module, Rights, and choose Users. Select the user whose password was lost and on the Edit menu, choose Modify password. Enter a new password and confirm this password. It is not necessary to enter the old password. Click OK to activate the new password. The user can now log in using his new password.

During the production migration (after the data migration) copy the 4.5 passwords from the test migration environment to your production environment. You can use the statement below.

UPDATE [ProductionDB].dbo.T_UserRegistration

SET UserPassWord = T.UserPassword

FROM [TestDB].dbo.T_UserRegistration AS T

WHERE T.UserCode = [ProductionDB].dbo.T_UserRegistration.UserCode;

In the above statement, use the name of your production database instead of [ProductionDB] (2×) and the name of your test migration environment instead of [TestDB].

Make sure that users do not change their passwords in the 4.0 production environment after the test migration has been performed. If you use the procedure above, after the production migration, every user will have the unicode version of their password as it was prior to the test migration. Users newly added to the 4.0 production environment after the test migration has been performed, might not be able to log in after the production migration. You have to reset their password in the production environment.