If the errors reported during the SSMA migration have not been solved in step 41. View the migration report, solve them now. Do this by searching for ´S2SS´ in the files in the StoredProcs_MSSQL_UDTs_replaced and Triggers_MSSQL_UDTs_replaced folders.

Please refer to Appendix B: SSMA Conversion Errors To Be Solved for examples of errors and pointers to solutions.

Solve the 'functional' errors, i.e. the problems involving SQL statements that do compile in MS SQL Server, but show the wrong behavior.

Please refer to Appendix C: Functional Errors To Be Solved for examples of errors and pointers to solutions.

Run the script Translate_Report_ProgramCode.sql. This script repairs obsolete references in the tables T_ReportMain and T_DataModule.

Run the scripts Delete_Obsolete_ProgramParams.sql and Delete_Obsolete_Permissions.sql. This will repair the reports, permissions and scripts that depend on obsolete reports, program codes and scripts.

Run the Validate FKs and Rules.sql script.

Should there be any constraints that cannot be validated, adjust the column values that are not supported by the foreign key or check constraint. You may have overlooked something in the previous step.

Apply T-SQL changes to dynamic SQL in the data (not the IsahData). This involves the following columns in four standard tables:

T_ProgramDataPresets	SelectText
T_ReportSelectionParam	SQLDesc
T_SQLQuery	SqlQueryText
T_Dataset	SqlQueryText

The most likely items to be modified are described in Appendix D: Errors To Be Solved For Dynamic SQL.

The Migration Box provides two tools for these modifications:

1. Use the function on the Quote converter tab to convert double quotes to single quotes (item 1 in Appendix D). Click the Run button to start this process on the dynamic SQL statements in the tables listed above. Any items that are to be checked manually are logged.
2. Use the function on the Parameter check tab to check for stored procedure calls in which too many or duplicate parameters are passed on (items 2 and 3 in Appendix D). Click the Run button to start this process on the dynamic SQL statements in the tables listed above. Then adapt the stored procedure calls displayed in the list that is generated.

Note: SQL statements in any custom tables in which dynamic SQL has been saved must also be modified.

The scripts in T_ScriptList.Info must be modified:

• These scripts may contain dynamic SQL and/or stored procedure calls. Refer to Appendix D: Errors To Be Solved For Dynamic SQL for more information.
• Other connection components are used in the new version. The most important changes have been made to the properties of the TxQuery, TxStoredProc, TxUpdateSQL and TIsah7CDSQuery components. Please refer to the document Changed Behavior of COM Scripting Events for a complete list of changes.

Use the ObjectReferences.sql script to search for objects calling non-existing objects. Calls to non-existing objects are displayed on the Output tab.

For the standard Isah objects, it results in 52 references to an alias that was not recognized by the compiler at compilation time. These items are not displayed in the result. The same may be true for the customizations. If there are any calls to non-existing stored procedures, tables or columns, the calling object must be repaired.

If you comment out the last statement (DROP TABLE #ObjectRef), you can view other information from the #ObjectRef table, if required.

The Crystal Reports driver does not support the new datetime2 type. In custom Crystal reports, the datetime2, T_Date, T_DateTime, T_LastUpdatedOn, T_MandDate and T_MandDate_Now types in the parameter list and the result set must be replaced by datetime. If the Crystal report directly accesses a table with datetime2 columns, a view needs to be created in which the required conversion takes place. Example:

SELECT Convert(datetime, <ColumnName>) AS <ColumnName>

The report can now use the view instead of the table. You need to perform this operation in the database itself, as the custom objects have already been imported back into the database.

Use the Set datasource location option in Crystal Reports Designer to change the database connection of the custom Crystal Reports reports. Until now, the Sybase server was used; this must be changed into the Microsoft OLE DB Provider for SQL Server.