Many Oracle Forms applications are older than their users' careers: written for Forms 4.5 or 6i in client-server days, moved to the web with 9i, 10g, or 11g, and kept running since. Moving them to Forms 14.1.2 is rarely a rewrite. The .fmb source opens in the new Forms Builder, most of its code compiles unchanged, and Oracle provides tools for the rest.
This guide covers upgrading to Oracle Forms 14.1.2: what changed between releases, the steps of an upgrade in order, the Forms Migration Assistant that rewrites obsolete code, the RP2RRO library that keeps RUN_PRODUCT working, a legacy form upgraded from start to finish, and the configuration to carry over.
Sample Form for This Guide
The examples and screenshots use the sample form CH37_LEGACY, before and after the upgrade, from the Oracle Forms code repository on GitHub. Download them, open them in Forms Builder, and connect as CAREWELL to follow along.
| Form | File | What it shows |
|---|---|---|
| CH37_LEGACY | forms/ch37/ch37_legacy.fmb | The legacy form after the upgrade |
| CH37_LEGACY (before) | forms/ch37/ch37_legacy_before.fmb | The same form before the Migration Assistant ran |
The forms run against the CareWell Clinic sample schema, which you install first.
What Changed Between Releases
| Change | What it means for old applications |
|---|---|
| Client-server to web | Since Forms 9i, forms run only on the web, in a runtime process on a server. Code that worked with the user's computer, such as HOST, TEXT_IO, GET_FILE_NAME, READ_IMAGE_FILE, and OLE2, now works on the server; WebUtil's CLIENT_ versions bring it back to the user's computer. |
| The client | The Java applet in a browser gave way to the Forms Standalone Launcher and Java Web Start, because current browsers no longer run applets. |
| Removed features | Character mode; OLE and VBX containers; sound items; charts drawn by Oracle Graphics; menu parameters; the Performance Event Collection Services (PECS), replaced by Forms Trace; and dozens of built-ins from Forms 3 and SQL*Menu. |
| Reports | RUN_PRODUCT gave way to RUN_REPORT_OBJECT, and Oracle Reports itself is deprecated. |
| New in 14.1.2 | REST and JSON, JavaScript integration, database events, and more, which old applications may adopt later. |
| Platform | Java 17 or 21 on the server, the certified databases, and a WebLogic 14.1.2 domain. |
The Migration Assistant warns that GET_FILE_NAME compiles and runs without error, but no longer does what it did. For the client-side replacements, see how to use WebUtil in Oracle Forms.
Two Changes Without an Error
- Dates in DATETIME items are now converted between the server's and the user's time zones. An application upgraded from 11g or older sets FORMS_DATETIME_LOCAL_TZ=GMT in its environment file to keep the old behavior.
- A form compiled by an older release does not run in 14.1.2: every .fmx, .mmx, and .plx must be compiled again.
The Steps of an Upgrade
- Inventory. List every module (forms, menus, libraries, object libraries) with its source file, the libraries each attaches, and the object libraries it subclasses from. Missing sources are the first risk: a .fmx without its .fmb cannot be upgraded. frmcmp_batch module=... print_version=yes tells which release last saved a module.
- Keep the originals. The new Forms Builder saves modules in its own format, which older releases cannot open, so upgrade copies.
- Convert very old modules. Modules from Forms 4.5, and menus from SQL*Menu 5.0, are converted by the Forms Compiler first with frmcmp_batch module=... upgrade=yes; upgrade_roles=yes turns SQL*Menu's table privileges into database roles.
- Convert obsolete code with the Forms Migration Assistant.
- Compile everything: libraries first, then object libraries, menus, and forms, each with compile_all=yes, so no code compiled by the old release remains. See how to compile Oracle Forms modules.
- Fix what remains. The compiler's errors and the Migration Assistant's warnings name the code to change by hand.
- Carry the configuration over, and test the application's behavior, its reports, and every piece of code that worked with the user's computer.
The Forms Migration Assistant
The Forms Migration Assistant, frmplsqlconv, reads a module, replaces obsolete built-ins with their modern equivalents, and writes a log of every change and warning. It runs as a wizard (mode=wizard) or, for scripts, on one module at a time.
Example:
frmplsqlconv.sh module=/work/forms/ch37_legacy.fmb userid=carewell@FORMSPDB log=convert.log
Its Replacements
Its rules are in search_replace.properties, in the Forms instance's directory. Some are replacements:
| Old code | Becomes |
|---|---|
| RUN_PRODUCT | RP2RRO.RP2RRO_RUN_PRODUCT |
| CHANGE_ALERT_MESSAGE | SET_ALERT_PROPERTY |
| COMMIT, ROLLBACK | COMMIT_FORM, CLEAR_FORM |
| ROLLBACK_FORM, ROLLBACK_NR, ROLLBACK_RL | CLEAR_FORM(NO_COMMIT, FULL_ROLLBACK) |
| OS_COMMAND, OHOST | HOST |
| MENU_MESSAGE, MENU_NEXT_FIELD, MENU_SUCCESS, and the other MENU_ built-ins | MESSAGE, NEXT_ITEM, FORM_SUCCESS, and so on |
| ENABLE_ITEM, DISABLE_ITEM | ENABLEDISABLEITEM library procedures |
| :UN, :PW | GET_APPLICATION_PROPERTY(USERNAME), (PASSWORD) |
| BREAK | DEBUG.SUSPEND |
Its Warnings
The other rules are warnings, for code that has no automatic replacement: the built-ins of OLE, VBX, and sound items; PECS; SQL*Menu built-ins such as MAIN_MENU and SHOW_MENU; menu parameters; hard-coded user exits such as USER_EXIT('HOST'); DATA_PARAMETER with RUN_REPORT_OBJECT; and GET_FILE_NAME. The rules file can be edited, to add an organization's own replacements before a large upgrade.
A Legacy Form, Upgraded
The sample legacy form is written as older releases allowed: it prints the week's schedule with RUN_PRODUCT, changes an alert's message with CHANGE_ALERT_MESSAGE, and saves with a bare COMMIT.
Example (WHEN-BUTTON-PRESSED trigger on CTL.PRINT, before the upgrade):
declare
v_params paramlist;
v_button number;
begin
v_params := create_parameter_list('TMPDATA');
add_parameter(v_params, 'P_FROM', text_parameter, '2026-11-16');
add_parameter(v_params, 'P_TO', text_parameter, '2026-11-22');
add_parameter(v_params, 'PARAMFORM', text_parameter, 'NO');
run_product(REPORTS, '/work/reports/cw_appt_schedule', SYNCHRONOUS, RUNTIME,
FILESYSTEM, v_params, NULL);
destroy_parameter_list(v_params);
change_alert_message('CW_NOTE', 'The schedule was printed.');
v_button := show_alert('CW_NOTE');
end;Example (WHEN-BUTTON-PRESSED trigger on CTL.SAVE, before the upgrade):
commit;
Forms 14.1.2 refused to compile it.
Output:
Compiling WHEN-BUTTON-PRESSED trigger on PRINT item in CTL data block... PL/SQL ERROR 201 at line 9, column 3 identifier 'RUN_PRODUCT' must be declared
The Migration Assistant's Changes
CHANGE_ALERT_MESSAGE and COMMIT still compiled: obsolete code is not always an error. The Migration Assistant changed all three and logged them.
Output:
Physical file name: /work/forms/ch37_legacy.fmb CH37_LEGACY.CTL.PRINT.WHEN-BUTTON-PRESSED: CHANGE_ALERT_MESSAGE changed to SET_ALERT_PROPERTY CH37_LEGACY.CTL.PRINT.WHEN-BUTTON-PRESSED: RUN_PRODUCT changed to RP2RRO.RP2RRO_RUN_PRODUCT CH37_LEGACY.CTL.SAVE.WHEN-BUTTON-PRESSED: COMMIT changed to COMMIT_FORM
It marked each trigger it changed, and did two more things: it attached the library rp2rro to the form, and created a report object named RP2RRO, both with a comment naming the Migration Assistant. The trigger afterward looked like this.
Output:
/*******************************************
Code modified by the Forms Migration Assistant
28-Sep-2026 10:14 AM
*******************************************/
declare
...
rp2rro.rp2rro_run_product(REPORTS, '/work/reports/cw_appt_schedule', SYNCHRONOUS, RUNTIME,
FILESYSTEM, v_params, NULL);
destroy_parameter_list(v_params);
SET_ALERT_PROPERTY('CW_NOTE', ALERT_MESSAGE_TEXT, 'The schedule was printed.');
...Keep RUN_PRODUCT Working with RP2RRO
rp2rro.pll, installed in the forms directory of the Oracle home, has a procedure RP2RRO_RUN_PRODUCT for each way RUN_PRODUCT could be called. Each runs the report with RUN_REPORT_OBJECT through the report object RP2RRO and, for a report meant for the screen, opens its output with WEB.SHOW_DOCUMENT, without rewriting the calls.
It needs to know the Reports server, and optionally the destination and format, from its procedures SETREPORTSSERVER, SETDESTYPE, SETDESFORMAT, SETDESNAME, and SETOTHERS, or from globals or form parameters named rp2rroReportServer, rp2rroDestype, and so on. The legacy form sets them when it starts, in a trigger added after the conversion.
Example (WHEN-NEW-FORM-INSTANCE trigger, added after the upgrade):
rp2rro.setReportsServer('rep_wls_reports_formslab');
rp2rro.setDestype('cache');
rp2rro.setDesformat('pdf');Compiled with rp2rro.pll in FORMS_PATH, the form ran the report as job 9, and the job's output URL returned the PDF; the new alert message followed.
RP2RRO builds the output URL relative to the Forms server, /reports/rwservlet/getjobid9?..., which reaches Reports when both are behind one web server, such as Oracle HTTP Server. It keeps an old application running while its RUN_PRODUCT calls are rewritten, one by one, as report objects of their own, as described in how to run Oracle Reports from a form.
Carry the Configuration Over
The old installation's configuration is not copied; it is recreated in the new domain:
| Item | What to do |
|---|---|
| formsweb.cfg sections | Recreate each in Fusion Middleware Control. Applet parameters, baseHTML and the jpi_ parameters, no longer matter for the Standalone Launcher, and userid values are entered again, because each domain encrypts them with its own key. |
| Environment files | FORMS_PATH with the new directories, NLS_LANG, the FORMS_ variables the application relied on, and FORMS_DATETIME_LOCAL_TZ for applications from 11g or older. |
| Registry.dat | The icon path and font mappings. |
| JAR files of icons, beans, and PJCs | Compiled again for the new Java if their source is available, signed, and listed in the archive. Java beans that used classes of the old applet may need changes. |
| WebUtil | The new release's webutil.pll and webutil.olb, attached and subclassed again, and webutil.cfg. |
| Reports | The Reports server's name, and COMPONENT_CONFIG_PATH in the environment file. |
| Security | Single sign-on moves to Oracle Access Manager; database roles and application tables need no change. |
The configuration files are covered in how to configure formsweb.cfg and how to set the Oracle Forms runtime environment.
Conclusion
An upgrade to Oracle Forms 14.1.2 recompiles everything from source, because .fmx, .mmx, and .plx files of older releases do not run in 14.1.2, and upgraded .fmb files no longer open in older ones. Inventory the modules, keep the originals, run the Forms Migration Assistant to replace obsolete built-ins and list what it cannot, and use RP2RRO to keep RUN_PRODUCT working through RUN_REPORT_OBJECT until each call is rewritten. Then recreate the configuration in the new domain, including sections, environment, JARs, WebUtil, and Reports, and test every client-side feature.
