A custom Background Job periodically fails against records that are simultaneously open in the UI, sometimes reporting the record as FND_LOCKED, and also causes users actively viewing the same record to get a 'record has been changed' error when they try to save — is there a way to check for currently-locked/in-use records so the job can simply skip them and pick them up on its next scheduled run?

Q: A custom Background Job periodically fails against records that are simultaneously open in the UI, sometimes reporting the record as FND_LOCKED, and also causes users actively viewing the same record to get a 'record has been changed' error when they try to save — is there a way to check for currently-locked/in-use records so the job can simply skip them and pick them up on its next scheduled run?

Query TRANSACTION_SYS_LOCAL_TAB to check for records currently involved in an active or failed transaction — this reflects records that are effectively locked/in-use at the point the query runs. Having the background job's own logic check this table first and skip any record it finds there (rather than attempting and failing against it) lets those records simply get picked up cleanly on the job's next scheduled execution instead of generating a lock conflict against an actively open UI session.

Answer

Query TRANSACTION_SYS_LOCAL_TAB to check for records currently involved in an active or failed transaction — this reflects records that are effectively locked/in-use at the point the query runs. Having the background job's own logic check this table first and skip any record it finds there (rather than attempting and failing against it) lets those records simply get picked up cleanly on the job's next scheduled execution instead of generating a lock conflict against an actively open UI session.

← Browse Developer Studio, deployment, and upgrades questions