Related terms
BIX extracts and writes out a batch of records at a time. These events, including any error messages, are recorded in the PegaBIX log file. Inspecting the file can provide insights into what caused problems during a data extraction.
Errors normally cause the BIX application to terminate. The application may continue to run following certain exceptions:
Committing an extract batch of class instances to a relational database may be interrupted because of issues with the data, syntax errors, a database constraint violation, or some other issue raised by the database.
Different databases respond differently to batch update exceptions. Generally, the database throws a BatchUpdateException error, which BIX records in the PegaBIX log file.
When an error occurs, BIX behaves differently depending on the database platform that it is working with: Oracle, MS-SQL, DB2 LUW, or DB2 for z/OS servers.
The server continues processing the operations in a batch even if one of the operations caused a database error. The database returns an exception that contains the exact information of the record in error to pinpoint the failure of the pzInskey of the record involved.
In this scenario, BIX supports two modes of execution:
In default mode, all successful inserts are committed and the pzInsKeys of the failing entries are listed in the log file.
To rectify the work object and rerun the extract, specify the same value for pzInskey in the –z and –Z options.
Note: When the –f option is in effect, the extraction process terminates after the first error is encountered. All successful batch inserts up to that point are committed. The batch which caused the failure is rolled back completely.
Oracle stops processing the remaining operations in the batch if it encounters an error. The exception returned by the database does not point to the exact operation that caused the exception. For that reason, all of the pzInsKeys of the records in the batch are included in the BIX error log. The records from the batch that were successfully committed are not indicated because the Oracle driver does not provide that information.
In this scenario, BIX supports two modes of execution:
In default mode, all successful inserts up to the record that failed are committed and the entries in the batch that followed the error entry are not processed. All of the pzInsKeys of that batch are written out to the log file.
To rectify the error and rerun BIX for the remaining records in the batch, specify the pzInsKey range for the remaining records using the –z and –Z options.
Note: When the –f option is in effect, the extraction process terminates after the first error is encountered. All of the successful batch inserts up to that point are committed. The batch that caused the failure is rolled back completely.