A script-enabled browser is required for this page to function properly.

Commit Processing

Commit processing is the way Oracle Forms attempts to make the data in the database identical to the data in the form. Oracle Forms's normal cycle of operation is:

  1. Read records from the database.
  2. Allow the end user to make tentative insertions, updates, and deletions. The tentative changes appear only in the form. The database remains unchanged.
  3. Post changes to the database. Oracle Forms does all of its remaining processing and sends the data to the database. After posting the data, Oracle Forms can only roll back the changes (via the [Clear Form] function key or CLEAR_FORM Built-in) or commit them.
  4. Oracle Forms commits the posted changes. They become permanent changes to the database.

The term commit processing refers to steps 3 and 4 of the above cycle. Normally these steps occur together. In response to the [Commit] key or invocation of the COMMIT_FORM Built-in, Oracle Forms firsts posts, then commits the data to the database.

Posting can occur separately before committing. End users cannot issue posting commands, but triggers can invoke the POST Built-in.

Note: Oracle Forms does not support a commit that does not include the normal Oracle Forms commit processing. For example, Oracle Forms does not support a commit issued from an Oracle Precompiler user exit or from a stored procedure.

Processing inserts, updates, and deletes

Posting consists of sending tentative changes from the form to the database. These are records that have been marked for insertion, update, or deletion since the last post. During posting, Oracle Forms processes inserts, updates, and deletes for all blocks in a form. Oracle Forms has a standard way to process these changes. Triggers provide a flexible mechanism for altering the standard behavior.

Insert

An insert is the pending insertion of a row in the database. Each insert has an associated SQL statement, which Oracle Forms executes when it posts the insert. The statement has the following form:

INSERT INTO table [(column, column, . . .)]
VALUES (value, value, . . .);

table

The name of the base table for the current block.

column

A column corresponding to a base table item. If an item is a derived column, it does not appear in the column clause.

value

The value to insert into the corresponding column.

Update

An updateis the pending updateof an existing row in the database. Each updatehas an associated SQL statement, which Oracle Forms executes when it posts the update. The statement has the following form:

UPDATE table
SET (column=value, column=value, . . .)
WHERE ROWID=rowid_value;

table

The name of the base table for the current block.

column

A column corresponding to a base table item. If an item is a derived column, it does not appear in the column clause.

value

The value to updatethe corresponding column.

rowid_value

The ROWID value for the row Oracle Forms is updating.

Note:

The WHERE clause specifies only a ROWID value. This identifies the unique row that the database should update. Oracle Forms uses the ROWID construct only when the block's Key Mode property has the value Unique_Key (the default).

If an end user does not have updateprivileges for a column, and the block's Enforce Column Security property has the value Yes, Oracle Forms does not include the column in the UPDATE statement. Different end users can have different UPDATE statements, depending on their privileges, but the statement remains unchanged during an end user's Oracle Forms session.

Delete

A delete is the pending deletion of a row in the database. Each delete has an associated SQL statement, which Oracle Forms executes when it posts the delete. The statement has the following form:

DELETE FROM table WHERE ROWID=rowid_value;

table

The name of the base table for the current block.

rowid_value

The ROWID value for the row Oracle Forms is deleting.

Note: The WHERE clause specifies only a ROWID value. This identifies the unique row that the database should delete. Oracle Forms does not use the ROWID value for non-Oracle data sources.

Caution: If a commit fails, the ROWID value may not have a null value. Use record status rather than the ROWID value to test for success or failure of the commit.

When commit processing occurs

Oracle Forms performs commit processing when

The alert appears as a result of any of the following:

database items in any block of the form have changed since the last commit, and any of the following events occurs:

Note: When a PL/SQL block issues a database commit from within Oracle Forms (via the SQL COMMIT statement), Oracle Forms commit processing occurs as if the COMMIT_FORM Built-in had been invoked.

Changing data during commit processing

Commit processing performs validation and can fire triggers. As a result, a commit event can change database items. For some triggers Oracle Forms attempts to commit those changes to the database during the current commit event.

Caution: Oracle Forms can commit unvalidated database changes made by the PRE-DELETE, PRE-INSERT, and PRE-UPDATE triggers.

For example, assume that a PRE-INSERT trigger selects a value into a base table item.

Caution: Oracle Forms can commit unvalidated database changes made by the POST-COMMIT, POST-DELETE, POST-INSERT, and POST-UPDATE triggers.

For example, assume that a POST-INSERT trigger selects a value into a base table item.

Replacing standard commit processing

The ON-INSERT, ON-UPDATE, and ON-DELETE triggers replace standard commit processing.