Oracle Forms Interview Questions and Answers: 25 Questions with Clear Explanations

Oracle Forms is Oracle’s tool for building data-entry and query screens directly on the Oracle Database, with business logic written in PL/SQL. Applications are designed in Forms Builder and run through the Forms Services runtime, with users accessing them through a browser-launched Java client or, in newer releases, the Forms Standalone Launcher.

• Form module: .fmb (source), .fmx (compiled)
• Menu module: .mmb / .mmx
• PL/SQL library: .pll / .plx
• Object library: .olb

A data block is based on a table, view, procedure or query, and Forms handles querying, inserting, updating and deleting automatically. A control block is not linked to any data source; it holds buttons, calculated fields or parameters.

Content (the base canvas of a window), stacked (displayed on top of a content canvas, often shown and hidden), tab (tab pages) and toolbar (horizontal or vertical toolbars).

A modal window must be closed before the user can work in other windows. A modeless window allows the user to switch freely between windows.

At form, block and item level. By default the most specific trigger fires – an item-level trigger overrides a block-level trigger of the same name – unless the execution hierarchy property is changed to fire before or after the higher-level trigger.

It fires when an item’s value has changed and the item is being validated, typically when the user navigates out of it. It is the right place for item-level business rules. Raising FORM_TRIGGER_FAILURE keeps the cursor in the item.

PRE-QUERY fires once before a block’s query is executed – used to add or change query criteria. POST-QUERY fires once for each fetched record – used to populate non-database items such as descriptions. Heavy SQL in POST-QUERY slows queries because it runs for every row.

PRE-INSERT, POST-INSERT, PRE-UPDATE, POST-UPDATE, PRE-DELETE, POST-DELETE, PRE-COMMIT and POST-COMMIT. A typical use of PRE-INSERT is assigning a primary key from a sequence.

-- PRE-INSERT on the ORDERS block
SELECT orders_seq.NEXTVAL INTO :orders.order_id FROM dual;

ON- triggers such as ON-INSERT, ON-UPDATE, ON-LOCK and ON-ERROR replace Forms’ default processing. For example, ON-INSERT can call a stored procedure instead of the default insert. ON-ERROR lets you show friendly messages instead of default error text.

Restricted built-ins affect navigation (for example GO_ITEM, GO_BLOCK, NEXT_RECORD) and cannot be used in triggers that fire during navigation or validation, such as WHEN-VALIDATE-ITEM. Unrestricted built-ins (for example SET_ITEM_PROPERTY, MESSAGE) can be used in any trigger.

• CALL_FORM opens another form while keeping the calling form active in the background; control returns when the called form exits.
• OPEN_FORM opens another form in parallel, allowing the user to switch between independent forms.
• NEW_FORM exits the current form and replaces it with the new one.

Use SET_BLOCK_PROPERTY with DEFAULT_WHERE to change it for subsequent queries, or ONETIME_WHERE to apply it to the next query only, then call EXECUTE_QUERY.

SET_BLOCK_PROPERTY('ORDERS', DEFAULT_WHERE, 'status = ''OPEN''');
GO_BLOCK('ORDERS');
EXECUTE_QUERY;

DECLARE
  l_btn NUMBER;
BEGIN
  l_btn := SHOW_ALERT('CONFIRM_DELETE');
  IF l_btn = ALERT_BUTTON1 THEN
    DELETE_RECORD;
  END IF;
END;

It posts all pending changes in the form to the database (firing the relevant validation and transactional triggers) and then commits. :SYSTEM.FORM_STATUS can be checked afterwards to confirm the result.

A relation object links a master and a detail block by a join condition. Forms then coordinates the detail query automatically. Delete behaviour can be non-isolated (prevent master delete while details exist), cascading (delete details too) or isolated (delete only the master).

A record group is an in-memory table of rows, often based on a query. An LOV is the pop-up list the user sees, and it gets its data from a record group. One record group can feed several LOVs.

Global variables (:GLOBAL.name) are character values available to all forms in the session. Parameters are declared in a form and passed in through a parameter list when calling it – a cleaner, more explicit way to pass values between forms.

A property class is a reusable set of properties that objects inherit, ensuring consistency. A visual attribute holds font and colour settings that can be applied to items, often changed at runtime, for example to highlight the current record.

:SYSTEM.CURSOR_ITEM, :SYSTEM.CURSOR_BLOCK, :SYSTEM.CURSOR_RECORD, :SYSTEM.FORM_STATUS, :SYSTEM.RECORD_STATUS, :SYSTEM.MODE (NORMAL or ENTER-QUERY) and :SYSTEM.TRIGGER_ITEM.

In web-deployed Forms, use RUN_REPORT_OBJECT to submit the report to the Reports Server, then WEB.SHOW_DOCUMENT to display the output in the browser. Older client-server code using RUN_PRODUCT must be converted during upgrades.

Use the Forms compiler from the command line (frmcmp or frmcmp_batch, depending on the version and platform) in a script that loops over all .fmb, .mmb and .pll files, so every module is compiled against the same libraries and database.

Rules that must apply no matter which screen or API changes the data belong in database packages and constraints. Forms triggers should focus on user interaction and call those packages. This also makes a later move to APEX much easier.

To get browser-native, mobile-friendly screens without Java client plugins, reduce middleware complexity, attract developers more easily and reuse existing PL/SQL. Read Oracle Forms vs Oracle APEX for a full comparison.

Check the queries first: indexes for search criteria, avoiding per-row lookups in POST-QUERY (use views or joins), limiting rows fetched, and reducing unnecessary round trips in WHEN-VALIDATE triggers. Trace the session in the database to find the slow SQL.