What is Oracle Forms?

Oracle Forms is a Rapid Application Development (RAD) tool for building database-centric applications. For over 20 years (from the mid-1990s through the early 2010s), it was the standard UI technology for Oracle's enterprise applications — including Oracle Retail Merchandising System (RMS) versions through v14.

Forms allowed developers to build rich, interactive screens that communicated directly with the Oracle Database. A single Forms developer could build a complete CRUD (Create, Read, Update, Delete) application in hours — something that would take days in traditional web development.

The Forms Architecture

Oracle Forms uses a three-tier architecture in its modern incarnation (Forms 12c):

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   BROWSER    │────▶│  WEBLOGIC    │────▶│  FORMS       │────▶│   ORACLE     │
│              │     │  SERVER      │     │  RUNTIME     │     │   DATABASE   │
│  Java Applet │     │              │     │  ENGINE      │     │              │
│  (or JRE     │     │ Servlet:     │     │              │     │ Tables,      │
│   Plugin)    │     │ frmservlet   │     │ Executes     │     │ Views,       │
│              │     │              │     │ FMX files    │     │ PL/SQL       │
│ Renders UI   │     │ Manages      │     │ PL/SQL       │     │ Packages     │
│              │     │ Sessions     │     │ triggers     │     │              │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘

Key architectural points:

• The Forms Runtime Engine runs on the server (not in the browser)
• The browser only receives display instructions (draw a text field here, draw a button there) via the Java applet
• All PL/SQL trigger logic executes server-side
• Database connections are maintained by the Forms Runtime, one per user session

Module Types: FMB, FMX, PLL, OLB

Oracle Forms uses several file types:

Trigger Architecture & Execution Order

The trigger system is the heart of Oracle Forms. Triggers are PL/SQL blocks that execute in response to events. Understanding their execution order is critical for debugging.

Trigger Levels

Triggers can be defined at three levels, with a specific firing order:

1. Form Level — Fires for any event anywhere in the form
2. Block Level — Fires for events within a specific data block
3. Item Level — Fires for events on a specific field

Navigation Trigger Execution Order

When a user opens a form and navigates to a record, triggers fire in this exact sequence:

FORM OPENED:
  1. PRE-FORM                     (Form Level)
  2. PRE-BLOCK                    (Block Level - first navigable block)
  3. WHEN-NEW-FORM-INSTANCE       (Form Level)
  4. WHEN-NEW-BLOCK-INSTANCE      (Block Level)
  5. PRE-RECORD                   (Block Level)
  6. WHEN-NEW-RECORD-INSTANCE     (Block Level)
  7. PRE-TEXT-ITEM                 (Item Level - first navigable item)
  8. WHEN-NEW-ITEM-INSTANCE       (Item Level)

USER NAVIGATES TO NEXT ITEM:
  9. WHEN-VALIDATE-ITEM           (Item Level - validates current item)
  10. POST-TEXT-ITEM               (Item Level - leaving current item)
  11. PRE-TEXT-ITEM                (Item Level - entering next item)
  12. WHEN-NEW-ITEM-INSTANCE      (Item Level - fire on new item)

USER SAVES (COMMITS):
  13. WHEN-VALIDATE-ITEM          (Current item)
  14. WHEN-VALIDATE-RECORD        (Current record)
  15. PRE-COMMIT                  (Form Level)
  16. PRE-INSERT / PRE-UPDATE     (Block Level - per row)
  17. ON-INSERT / ON-UPDATE       (Block Level - actual DML)
  18. POST-INSERT / POST-UPDATE   (Block Level - per row)
  19. POST-FORMS-COMMIT           (Form Level)
  20. POST-DATABASE-COMMIT        (Form Level - after COMMIT issued)

Key Triggers for RMS Developers

Data Blocks & Canvas Architecture

Data Blocks

A data block is the link between a form and a database table (or view). Key properties:

• Query Data Source Name: The table or view the block queries (e.g., ITEM_MASTER)
• DML Data Target Name: The table the block inserts/updates/deletes against
• Records Displayed: How many rows are visible at once
• Query All Records: Whether to fetch all rows or use on-demand scrolling

Canvas Types

• Content Canvas: The standard canvas — a single scrollable form area
• Stacked Canvas: A canvas layered on top of a content canvas — used for modal dialog-like behavior
• Tab Canvas: A tabbed interface where each tab shows different fields for the same record
• Toolbar Canvas: A horizontal toolbar with buttons and status indicators

LOV (List of Values)

LOVs are popup query windows that allow users to search and select values. In RMS Forms, LOVs are used extensively:

• Supplier LOV — search suppliers by name, number, or status
• Item LOV — search items by item number, description, UPC, or department
• Location LOV — search stores/warehouses by number or name

Oracle Forms in RMS (v14 and Earlier)

Oracle RMS v13 and v14 used Oracle Forms as the primary user interface. Key characteristics:

• ~500 Forms: A large RMS installation had hundreds of forms covering item management, purchase orders, pricing, inventory, supplier management, and administration
• Complex Forms: The Item Master form alone had 15+ tabs, dozens of blocks, and hundreds of triggers
• Tight Database Coupling: Forms queried base RMS tables directly — no abstraction layer
• Customization Challenges: Retailers frequently modified base forms (adding custom fields, changing validation logic), creating massive upgrade headaches

The Customization Problem

When a retailer customized a base Oracle Forms module (e.g., added a custom field to the PO form), they owned that customization forever. Every Oracle patch and upgrade required manually merging Oracle's changes with the retailer's customizations — a process that could take months for a major upgrade.

The Java Applet Crisis

Oracle Forms ran in browsers via Java applets — small Java programs embedded in web pages using the browser's Java plugin (NPAPI). This worked well from 1998 through approximately 2015.

Then the crisis hit:

1. 2015: Google Chrome removes NPAPI support. Forms no longer works in Chrome.
2. 2016: Mozilla Firefox follows suit. Forms stops working in Firefox.
3. 2018: Microsoft Edge (Chromium) never supports NPAPI.
4. 2020: Oracle itself deprecates the Java browser plugin.

Suddenly, the only browser that could run Oracle Forms was Internet Explorer — a browser that Microsoft itself was deprecating. Retailers running RMS v14 faced a severe dilemma: their core business application could only run in an obsolete browser.

Workarounds

• Java Web Start: Launched the Forms applet as a standalone Java application (outside the browser). Required JRE installation on every desktop.
• Citrix/VDI: Ran Internet Explorer in a virtual desktop environment, isolating the legacy browser dependency.
• Upgrade to v16+: Migrated to RMS v16 or v19, which replaced Forms with ADF and then Oracle JET web UIs.

Forms-to-APEX Migration Path

For retailers with custom Oracle Forms applications (not part of the RMS base), Oracle APEX is the recommended migration target.

Migration Approach

1. Inventory: Catalog all custom Forms modules (FMBs), their data sources, and their business logic
2. Assess Complexity: Rate each form (simple CRUD → complex multi-block with extensive triggers)
3. Prioritize: Migrate high-value, high-usage forms first
4. Redesign: Don't replicate the Forms UI in APEX. Redesign for a modern web experience:
   • Replace Forms LOVs with APEX interactive reports and faceted search
   • Replace stacked canvases with modal dialogs
   • Replace tab canvases with APEX sub-regions
5. Migrate Logic: Move PL/SQL trigger logic to database packages (where it should have been all along)
6. Test: Comprehensive testing of every CRUD operation, validation rule, and business logic path

Maintenance Best Practices

For teams still maintaining Oracle Forms applications: