25.4 Managing Legacy Tabular Forms

A legacy tabular form enables users to update multiple rows in a table at once from a single page.


A tabular form is a legacy application component. Although existing legacy tabular forms are supported, the creation of new legacy tabular forms has been desupported. Oracle recommends developers create interactive grids instead.

A legacy tabular form enables users to update multiple rows in a table at once from a single page. A legacy tabular form enables you to perform update, insert, and delete operations on multiple rows in a database table. Tabular forms include a built-in multiple row update process that performs optimistic locking behind the scenes to maintain the data integrity.

25.4.1 Best Practices When Managing Tabular Forms

Oracle recommends the following best practices when managing tabular forms:

  • Do not modify of the select list of a SQL statement of a existing legacy tabular form. If you must modify the query, make sure the values of the updatable columns are not altered after being queried from the database by the Oracle APEX engine.

  • Do not add custom JavaScript to display types that use display type specific JavaScript logic (for example, radio groups, simple checkboxes, and popup key LOVs).

25.4.2 How Legacy Tabular Forms Work

Tabular forms are based on a SQL query in which the query columns are tied to the underlying table columns. Unlike a single record from, tabular forms do not store data in session state. When a tabular form page is submitted, the tabular form data is processed using built-in data manipulation language (DML), or a custom PL/SQL page processes.

A tabular form with automatic DML has two processes for multi-row operations:

  • A Multi Row Update (MRU) process performs create and update operations.

  • Multi Row Delete (MRD) process deletes requests on one or more rows.

MRU and MRD processes reference the underlying table name and the primary key columns. The primary key columns must be part of the tabular form SQL query, and the report columns must be either hidden or display-only (save state) in order for the DML processes to be able to identify the correct records. For new records, the primary key values must be NULL to be identified as new records. Delete operations are performed by referencing row number of the row to be deleted. Users can check one or more rows on the current page and when they click the Delete button, the row numbers identify the corresponding primary key value(s) and the matching rows are deleted.

Wizard generated tabular forms built-in DML includes a checksum column to prevent lost updates. Using a method called optimistic locking, a checksum is computed for each row when rendering a tabular form. This checksum is stored in an extra hidden tabular form column. Upon submission of the form for update, an additional set of checksums is computed on the then current data stored in the database. The new checksums are compared to those built when the tabular form was first rendered, and if there are any mismatches, the update is rejected, because the data in the database was either modified by another user or anther process in the time between the tabular form was rendered and the time the data was submitted.

25.4.3 About Running a Legacy Tabular Form

When running a tabular form, data is rendered as a report having updatable columns shown using various form elements (including text fields, text areas, date pickers, select lists, radio groups, and so on).

For numeric and date fields, you can also pre-define date and number format masks, or apply those format masks after generating the initial form.

Each report also includes a checkbox column (called a row selector). Users use this row selector to select one or more columns and update or delete data. To add a row, users click Add Row.


You can control the appearance of a specific column by editing column attributes.

See Also:

Managing User Interface Defaults in Oracle APEX SQL Workshop Guide