Answer
This is the classic 'mutating table' problem: you can't reliably query/modify the same table an event's own triggering DML is still in the middle of acting on. The two standard resolutions are wrapping the fetch-and-update logic in a PL/SQL block marked with PRAGMA AUTONOMOUS_TRANSACTION (which runs and commits independently of the main triggering transaction — a reasonable fix, but be aware it commits separately, so if the outer triggering transaction later rolls back, your autonomous update won't roll back with it), or deferring the actual update to run via a background job (queued from the event rather than executed inline), which naturally avoids the mutating-table conflict since it runs in a completely separate later transaction. Which approach is more appropriate depends on whether you need the custom field update to be strictly atomic with the original change (background job, at the cost of a small delay) or you're comfortable with the autonomous-transaction tradeoff for something that needs to happen immediately.