A Custom Event using Execute Online SQL needs to update another field on the very same record currently being inserted (using a function's result), but doing this directly inside the event risks a table-mutation error — what's the safer pattern?

All FAQ questions / Platform, Aurena, and customization

Answer

Rather than attempting the update directly inside the insert-triggered event (which risks a mutating-table error), trigger a background job instead: build an attribute string with the relevant key/field values from the record (using Client_SYS.Add_To_Attr), then call Transaction_SYS.Deferred_Call, passing a custom procedure name, the attribute string, and a description — the deferred call runs as a separate background job after the main insert transaction has fully completed, avoiding the mutating-table conflict entirely while still letting the custom procedure read and update the just-inserted record's other fields.

Documentation-based answer. Confirm the product and release before applying it. This answer has not been verified in an IFS environment.

← Browse Platform, Aurena, and customization questions