|Oracle Migration Workbench Frequently Asked Questions (FAQ)
Release 9.2.0 for Microsoft Windows 98/2000 and Microsoft Windows NT
Part Number A97247-01
This chapter contains frequently asked questions about using the Oracle Migration Workbench to migrate an Informix Dynamic Server 7.3 database to an Oracle Server. It contains the following sections:
This section contains Informix Dynamic Server installation and configuration questions.
Yes. The following list includes the schema migration limitations for Informix Dynamic Server:
Use Informix Dynamic Server JDBC Driver 1.4 to connect to an Informix Dynamic Server. The Informix JDBC Driver 1.4 is available from the Informix Dynamic Server 7.3 CD.
To connect to an Informix Dynamic Server, you must copy the
ifxjdbc.jar Informix Dynamic Server JDBC driver file to the
%ORACLE_HOME%\Omwb\drivers directory before running the Migration Workbench. Otherwise, when you attempt to capture a Migration Workbench database, you receive the following error message:
If you receive this error message, copy the
ifxjdbc.jar file to the
%ORACLE_HOME%\Omwb\drivers directory, then restart the Migration Workbench.
This section contains Informix Dynamic Server data migration questions.
If you use the default repository, the Defaults schema objects are not migrated from an Informix Dynamic Server source database to an Oracle destination database. To ensure that schema objects are migrated, select an Oracle9i or Oracle8i repository in the Oracle Migration Workbench Repository Login dialog box.
For more information on schema object limitations, see Schema Object Similarities in the Oracle Migration Workbench Release Notes. The release notes are available from the Oracle Migration Workbench Online Help and from the Documentation section of the OTN Web site at:
This is a known problem with the stored procedure parsing. To avoid it, manually edit the code. You can do this by editing the stored procedures schema object of the Oracle Model. Alternatively, you can edit the stored procedure in the Oracle database after the migration process is complete.
The following table displays the incorrect parsing output and the correct output for the following stored procedure variable definition:
|Incorrect Parsing||Correct Parsing|
The stored procedure parser can fail if you use hard coded decimal numbers with missing leading or trailing zeros. This is a known problem with the Stored Procedure parser in the Migration Workbench. To prevent it from happening, insert leading or trailing zeros to the numbers in the stored procedure text. You can do this in either in the Informix Dynamic Server database or in the Source Model of the Migration Workbench. The following table shows examples of decimal numbers:
|Incorrect Format||Correct Format|
Yes. The limitations of the Informix Dynamic Server parser are:
SETstatements, with the exception of
SET DEBUG FILE. You might need to manually convert the
CASEstatements, for example
CASE WHEN e.sal > 2000 THEN e.sal ELSE 2000 END CASE. You might need to manually convert these types of statements.
DBINFOis only partially translated during conversion. You might need to manually convert this procedure.
DDLstatements within stored procedures, with the exception of the
No. The Migration Workbench does not fully support the migration of LOB data using SQL*Loader scripts.
unload command dumps binary data as a series of hexadecimal characters. Within a SQL*Loader control file, you can apply the
HEXTORAW SQL function to this field of hexadecimal character data to produce binary data. The Migration Workbench can then write binary data to a
LONG RAW column. The Migration Workbench will generate a control file to do this automatically.
You can use the Migration Workbench to generate the SQL*Loader control file for the table which stores binary data.
To generate the SQL*Loader control file:
SQL*Loadercontrol file generated by the Oracle Migration Workbench, verify that the maximum CHAR size is large enough for the dumped hexadecimal data, in the line for the column which stores the binary data.
Because the column in the Oracle database table is defined as
LONG, you must use a length specifier on the
CHAR keyword to specify a maximum length. The maximum length is 2 gigabytes for
LONG datatypes. Doing this guarantees that a large enough buffer is allocated for the value.
Ensure that the
The logical records being loaded must completely fit into the available memory on the system running SQL*Loader.