Why reading someone else's Oracle Forms application is hard
Most Oracle Forms applications that are still running were built by people who have since left. The screens work, the users know which buttons to press, and the documentation is either missing or describes a version from years ago. When someone finally has to change the application, or decide whether to move it to Oracle APEX or another target, the first job is the same: work out what it actually does.
The difficulty is that a Forms application does not keep its business rules in one place. They are spread across form modules, triggers, program units and database code. Reading it well means knowing where each kind of logic tends to live, and reading in an order that lets you find the rules before you find the clutter around them.
How forms, triggers, program units and PL/SQL fit together
A single form module (an FMB file) bundles several things that behave differently, so it helps to separate them before you read any code.
- Blocks and items. A block is a group of fields, usually tied to a database table or view. The block and item properties tell you which data a screen reads and writes.
- Triggers. These are PL/SQL snippets attached to events: opening the form, entering a record, leaving a field, saving. Each one runs at a specific moment, and the moment matters as much as the code.
- Program units. Named procedures and functions stored inside the form itself, called from triggers and from each other.
- Attached libraries. Shared PL/SQL libraries (PLL files) used by many forms. Logic here affects every form that attaches the library.
- Database objects. Packages, procedures and triggers in the database that the form calls or that fire when it saves data.
The same business rule can sit in any of these. A discount limit might be checked in a field-level trigger, repeated in a save trigger, and enforced again by a database package. Treat each of those as one rule with several implementations, not as three separate rules.
Reading Oracle Forms triggers in the right order
Triggers are where most of the surprises are, because they do not run in the order they appear on screen. Start with the ones that define a form's life cycle rather than the ones on individual fields.
- Form-level triggers first. Look at what happens on opening the form, on every new record, and on commit. These set up defaults, check permissions and decide what gets saved, so they frame everything else.
- Block-level validation next. Check the triggers that fire when a record is validated or a block is entered. This is where most data rules sit.
- Field-level triggers last. These are the most numerous and the most likely to be small tweaks or leftovers. Read them once you know what the form-level logic already does.
As you read, note three things for each trigger: what event starts it, what data it reads, and what it changes. A trigger that only formats a field for display is not a business rule. A trigger that rejects a save, calculates a payment, or changes a status is. Pay particular attention to triggers that call program units, because the real logic is often one level down.
Finding the business rules before you plan the move
Once you can read a form's structure, the aim is to pull the rules out of the plumbing. A useful working method is to take one business outcome at a time, such as how a total is calculated or when a record can be approved, and follow it through every layer that touches it.
- Start from a screen field or a table column and search for every trigger, program unit and package that references it.
- Write the rule in a sentence a business person would recognise, then note where each piece of it is enforced.
- Flag logic that exists only for the old technology, such as screen navigation, key handling and display tricks. This usually does not need to be carried into APEX or any other target.
- Flag rules that appear in more than one place with slightly different conditions. Those are the ones that cause defects after a migration.
Doing this by hand across dozens or hundreds of forms is slow, which is why many teams use tooling to build the map first. For a wider look at the approach, see our piece on legacy code analysis, and for how a field's value moves between screen and database, see data lineage in legacy systems.
From understanding to a migration plan
The point of reading the application is to make a decision with evidence. When you know which rules exist, where they live and how they connect, you can scope a move properly: which forms are simple screens over a table, which carry heavy logic, and which depend on shared libraries that need handling first.
That understanding feeds directly into planning. Our guide to the Oracle Forms to APEX migration plan covers scoping and execution, and the broader Oracle Forms migration guide looks at the options for enterprise teams. If you want to see how Replai approaches this, the Oracle APEX page explains how it maps business meaning in Forms code so your team can see what it is working with before changing anything.
Frequently asked questions
Where do the business rules live in an Oracle Forms application?
They are spread across form triggers, program units stored in the form, attached PL/SQL libraries and database packages. The same rule is often enforced in more than one of these places.
Which Oracle Forms triggers should I read first?
Start with form-level triggers that run when the form opens, when a record is created and when data is committed. Then read block-level validation, and leave individual field triggers until last.
What is the difference between a trigger and a program unit?
A trigger is PL/SQL attached to an event, such as entering a record or saving. A program unit is a named procedure or function stored in the form that triggers and other code call.
How do I tell a business rule from screen behaviour?
A rule changes, validates or rejects data, such as a calculation or a status change. Logic that only handles navigation, formatting or key handling is screen behaviour and usually does not need to be carried into a new platform.
Why do I need to find the rules before moving to APEX?
Rules that stay hidden get lost or duplicated when the screens are rebuilt. Knowing where each rule lives lets you scope the work and avoid defects after the move.
Do I have to read every form by hand?
You can, but it is slow across a large estate. Many teams use analysis tooling to build a map of rules and dependencies first, then review the important parts by hand.