The START AFTER COMMIT statement returns a result set with one INTEGER column. This integer is a unique job id that can be used to query the status of statements that failed to start for some reason, for example, invalid SQL statement, no access rights, replica not available, and so on.
If a maximum number of uncommitted deferred procedure call statements is reached, then an error is returned when the deferred procedure call is executed. The maximum number is configurable by using the Srv.MaxStartStatements parameter, see Srv section.
If a statement cannot be started, the reason is logged to the system table SYS_BACKGROUNDJOB_INFO, see SYS_BACKGROUNDJOB_INFO.
Only failed START AFTER COMMIT statements are logged into this table. If the statement (for example, a procedure call) starts successfully, no information is stored into the system tables.
User can retrieve the information from the table SYS_BACKGROUNDJOB_INFO by using either a SELECT query or by calling the system procedure SYS_GETBACKGROUNDJOB_INFO, see SYS_GETBACKGROUNDJOB_INFO.
Also, the event SYS_EVENT_SACFAILED is posted when a statement fails to start, see SYS_EVENT_SACFAILED. The NUMDATAINFO field contains the jobID. The application can wait for this event and use the jobID to retrieve the reason from the system table SYS_BACKGROUNDJOB_INFO.
The system table SYS_BACKGROUNDJOB_INFO can be emptied with the following command:
ADMIN COMMAND 'cleanbgjobinfo'
You need administrator privileges to execute this command, which means that only an administrator can delete the rows from the table.
The server uses the task type SSC_TASK_BACKGROUND for the tasks that execute statements that are started with START AFTER COMMIT. Note that there might be several of these tasks, but you cannot control them individually.