Modification History
Date / Name / Description
1999Oct24 Gary Wong * Creation (modified from
existing Forms 5 migration document)
2000Jan18 Dan MacDonald * webpage created;
some instructions revised
2000May17 Dan MacDonald * UPGRADE_PLSQL=YES
added to forms compiles
2000May17: A bug was found in the upgrade process whereby function declarations were not being changed (from CHAR to VARCHAR2); this can cause problems with OUT parameters. To fix this, the UPGRADE_PLSQL=YES directive must be added to the command line. This change has been made to this tool release; if you are using an older migration kit, either please upgrade it with this one, or edit the batch command files to include the UPGRADE_PLSQL=YES directive.
PACKAGE SETUP
Ensure that Forms 6 Developer is installed correctly
Download the ENVLIB v.60 toolset from the web
http://srmwww.gov.bc.ca/imb/oracle_support/apps/envlib.v60.zip
http://iwww.env.gov.bc.ca/isb/oracle_support/apps/envlib.v60.zip
(Intranet version currently not available)
Unzip into a directory in the FORMS60_PATH, such
as
d:\apps_nt\melp\6.0\forms\prod
Download the Forms45-to-Forms60 Migration package from the
web
http://iwww.env.gov.bc.ca/isb/oracle_support/apps/forms45-forms60-migration.zip
(Intranet version
currently not available)
Unzip these files into a working directory, such
as
d:\work\conversion
CONVERSION PROCESS
Copy the Forms4.5 source modules that you want to convert (.fmb, .mmb, .pll files) into the working directory where you extracted the Forms45-to-Forms60 Migration package
Ensure that you know the database schema and instance for each of the applications to be upgraded (i.e. SWIS, COORS, EMS, etc.)
Start a DOS window, with the current working directory set to the working directory
For each application to be upgraded, repeat the following steps:
For certain unavoidable errors (see list below), open the file in Forms Builder and correct the error.
Startup the application and spot check some of the form executables
Erase the .plg (PL/SQL upgrade logs) and .err (error
logs) files.
LIST OF UNAVOIDABLE ERRORS DURING UPGRADE
Some applications may have their own reference forms (i.e. SWIS_LIB.FMB) which aren't meant to be generated. This will result in errrors which you can safely ignore.
At compile-time Forms 6 checks the 'primary canvas'
and 'horizontal toolbar' properties of windows. The old template had inconsistent
settings on the DUMMY window which result in the following warning messages:
"FRM-30161: Inconsistent relationship between window
DUMMY and its primary canvas ."
"Window DUMMY"
"FRM-30162: Inconsistent relationship between window
DUMMY and its horizontal toolbar ."
"Window DUMMY"
This DUMMY window was generated into forms (not
referenced) so the only way to get rid of this warning message would be
to open up each file in Forms Builder and hit the 're-inherit' button for
the DUMMY window on these two properties. The .fmx still gets created so
you may safely ignore this message for intermediate testing purposes. Any
"final" delivery, through, must not contain this error.
At compile-time, Forms 6 will check the Designer-generated
procedure "CGFF$CALL_MODULE" and consistently find the following error.
"Compiling procedure CGFF$CALL_MODULE... "
"Compilation error on procedure CGFF$CALL_MODULE:"
"PL/SQL ERROR 307 at line 34, column 5 too many
declarations of 'RUN_PRODUCT' match this call"
"PL/SQL ERROR 0 at line 34, column 5"
"Statement ignored"
The actual line is:
"RUN_PRODUCT(REPORTS, P_MODULE_NAME, ASYNCHRONOUS, RUNTIME, FILESYSTEM, NULL, NULL);"
and the solution is to make it:
"RUN_PRODUCT(REPORTS, P_MODULE_NAME, ASYNCHRONOUS, RUNTIME, FILESYSTEM, '', NULL);"
Sixth parameter can be paramlist_id or paramlist_name; by making it '', we tell forms that it is a parmlist_name of null
NOTE: There may be a Forms 6 patch for this.
In rare cases, the TOOLBAR canvas will reset its Visible property to "Yes" (for example, in the main entry screen of an application, where the toolbar is not required). The solution is to manually reset it to "Visible=No".