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.

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

1. Start SSMA. Make sure you choose the 32-bit version.
2. Open the migration project created earlier.
3. In the Sybase section of the SSMA tool, select Tables. All tables are now selected.
4. Right-click Tables and choose Migrate Data.

   

5. Log onto the ASE server. You now have to wait for about four to eight hours.

   If the data of some tables are not migrated or only partly migrated because of a timeout error:

   • Save the data migration report (see step 60)
   • Select the failed tables in the Sybase section of the SSMA tool
   • Change the Migration Settings: Tools, Project Settings, Migration and change Batch size to 5,000 and Data migration timeout to 1440.

     

   • After storing the migration settings, restart the data migration for the failed tables. When a warning is shown that the data already present in these tables will be deleted, choose Continue. The old data will be deleted before the data are migrated again.

     

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.

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

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.

Alternatively, you can use the method described in step 59: Migrate the data.

1. Click the Load script button. The IdentityTables.sql script that was generated earlier is now displayed.
2. Click the Run script 1 button to create Identity columns for custom tables.
3. Click the Run script 2 button to re-create the triggers of the identity tables.

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

Run the Save_IsahData.sql 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.

Run the Check_Structure_MSSQL.sql script to check if all customizations still exist.

Any missing objects and tables with incorrect column definitions are reported. Do not forget to check the Output tab, since since the results of the import check are reported there.

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.