A `raise_application_error()` call inside a custom PL/SQL procedure correctly raises an error when run manually in a SQL terminal, but the same procedure called by a Background Job doesn't seem to produce any visible error for the user at all. Is there a different way error handling needs to be done specifically for code that runs as a background job?

Q: A `raise_application_error()` call inside a custom PL/SQL procedure correctly raises an error when run manually in a SQL terminal, but the same procedure called by a Background Job doesn't seem to produce any visible error for the user at all. Is there a different way error handling needs to be done specifically for code that runs as a background job?

Rather than using a raw raise_application_error() call, use the framework's own Error_SYS package instead (for example Error_SYS.Appl_General(' ', ' : ')) — Error_SYS is specifically designed to integrate with IFS's own background-job error-reporting mechanism, producing a properly readable, correctly formatted error message visible in the background job's log, whereas a bare raise_application_error() call may not surface in the expected user-visible way when the calling code is executed as a background job rather than run directly.

Answer

Rather than using a raw raise_application_error() call, use the framework's own Error_SYS package instead (for example Error_SYS.Appl_General('<YourLuName>', '<ERROR_CODE>: <your message>')) — Error_SYS is specifically designed to integrate with IFS's own background-job error-reporting mechanism, producing a properly readable, correctly formatted error message visible in the background job's log, whereas a bare raise_application_error() call may not surface in the expected user-visible way when the calling code is executed as a background job rather than run directly.

← Browse Developer Studio, deployment, and upgrades questions