Avoid mutating-table errors in IFS event actions
Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.
Fix an ORA-04091 mutating-table error caused by a custom event reading the same table while its row change is still being processed. First remove unnecessary reads by using event attributes; move genuinely post-transaction work to a supported asynchronous path.
Before you start
Section titled “Before you start”Use a development reproduction, the event’s configuration/export, and the failing error stack. Record the business action, entity/table, event ID, enabled actions, changed fields, and the exact package/function reported in the stack.
Do not edit a generated event trigger directly. Changes belong in the event configuration or an approved extension, followed by the normal publish/deployment process.
1. Isolate the failing action
Section titled “1. Isolate the failing action”Reproduce the error on one fictional record. In Custom Events, open the event for the relevant logical unit/table and inspect its selected firing conditions. Use Show Actions to list its actions.
Disable only the suspected custom action in development and repeat the same business change. If it now succeeds, re-enable it after recording the result and inspect that action’s expressions/custom attributes. If it still fails, the error may be in another event or business extension.
2. Replace same-row lookups with event values
Section titled “2. Replace same-row lookups with event values”In the event’s Attributes list, select the required New Value and Old Value fields. Publishing exposes substitution variables such as NEW:DESCRIPTION and OLD:DESCRIPTION.
For a changed Description, use the event editor’s parameter picker to insert the provided new/old values into the action. Do not call a custom function that SELECTs the same row merely to retrieve the value already available in the event.
A custom attribute function can itself perform a same-table read even if the action body contains no visible SELECT. Trace that function when reviewing the error stack.
3. Narrow the trigger
Section titled “3. Narrow the trigger”For an update event, select only the attributes whose changes should fire it. Leaving the changed-attribute selection broad can make unrelated updates run your action and can cause recursion if the action updates the same row.
Add an explicit condition for the intended old-to-new transition. For the lab, also restrict it to the fictional record. Publish/enable the event through the supported UI so the framework regenerates its trigger as needed.
Expected result: the original business save succeeds, and the action receives the changed value without querying the mutating table.
4. Move aggregate or remote work out of the row event
Section titled “4. Move aggregate or remote work out of the row event”If the action really needs all rows after the transaction, use a supported asynchronous workflow or application-message route. Pass the business key and immutable event context, then have the worker re-read the record after the originating transaction completes.
For a workflow, create/deploy the process first, then add a Workflow event action and choose the supported asynchronous timing. Verify the input names exposed to the workflow through inspection; event substitutions and workflow variable names are not interchangeable syntax.
Do not add a commit, autonomous transaction, or a sleep to make the error disappear. Those change consistency or timing rather than proving that the event reads a valid business state. Execute Online SQL is deprecated in Cloud guidance and should not be the default new solution.
5. Test transaction and replay behavior
Section titled “5. Test transaction and replay behavior”Run these cases and inspect both business data and notification/worker evidence:
| Case | Expected result |
|---|---|
| Intended field transition | One eligible action |
| Unrelated field update | No action |
| Business transaction rejected | No falsely completed downstream business effect |
| Multiple-row operation | Correct scope for each intended record |
| Worker retry | No duplicate business update |
| Record changed again before worker runs | Explicit handling of current state versus original event snapshot |
An asynchronous worker sees later committed state, which may differ from the original event’s values. Pass and compare a version/time/reference where the business requirement depends on the original transition.
6. Restore and document
Section titled “6. Restore and document”If the change fails acceptance, disable the new action and restore the exported event configuration through the supported import/publish process. Remove lab queues/workflows only after resolving pending work.
Record the failing stack, the removed same-table read, selected event attributes, final trigger condition, and actual positive/negative results. This evidence explains why the fix solves the mutating-table problem instead of merely suppressing the error.
Sources and scope
Section titled “Sources and scope”Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.