Analyzing failures in START AFTER COMMIT statements
There is a limit on the number of uncommitted START AFTER COMMIT statements that may exist simultaneously. (By “uncommitted”, we mean that the transaction in which the START AFTER COMMIT statement was executed has not yet been committed. At this point, the body of the START AFTER COMMIT statement — for example, the procedure call — has not yet even started to execute.) If the maximum is reached, then an error is returned when the next START AFTER COMMIT is issued. The maximum number is configurable in solid.ini using the parameter named MaxStartStatements (for details, see the description of this parameter in solidDB® Administrator Guide).
If a statement cannot be started, the reason for it is logged into the system table SYS_BACKGROUNDJOB_INFO. Only failed START AFTER COMMIT statements are logged into this table. For more details about this table, see SYS_BACKGROUNDJOB_INFO.
The user can retrieve the information from the tableSYS_BACKGROUNDJOB_INFO using either an SQL SELECT statement or by calling the system procedure SYS_GETBACKGROUNDJOB_INFO. The stored procedure SYS_GETBACKGROUNDJOB_INFO returns the row that matches the given jobid of the START AFTER COMMIT statement. For more details about SYS_GETBACKGROUNDJOB_INFO, see SYS_GETBACKGROUNDJOB_INFO.
If you want to be notified when a statement fails to start, you can wait on the system event SYS_EVENT_SACFAILED. See its description in Miscellaneous events for details about this event. The application can wait for this event and use the jobid to retrieve the error message from the system table SYS_BACKGROUNDJOB_INFO.