The Update driver uses two error tables for each target table:
| Error Table | Contents |
|---|---|
| ErrorTable1 = et1name | Records rejected because of:
|
| ErrorTable2 = et2name | Records that violate the unique primary index constraint. |
Reusing Table Names
When an error table has one or more rows, it is not dropped from the database at the end of an Update driver job. Use the DROP TABLE statement from BTEQ to remove the tables from the database so that you can reuse the names specified for the error tables.
Limiting Insertion Errors
Use the TD_ERROR_LIMIT attribute to restrict the number of insertion errors captured in the ErrorTable1 during the acquisition phase of an Update job.
| IF you expect your Update job to encounter... | THEN specify an ERRORLIMIT value that is... |
|---|---|
| No errors or very few errors | low |
| Many errors that are considered allowable | high |
The ErrorLimit specification applies to each instance of the Update driver, not to all instances combined. For example, you set the limit to 10,000 rows. A single instance must detect that 10,000 rows were inserted into the first error table to terminate the job, and those 10,000 rows must be controlled by the sessions managed by that instance.
If you expect no errors in the input data, set the error limit value to one. In this case, the job terminates when any record causes an error. However, when the specified error limit is reached, the Update driver continues processing until each session completes its current data block. This continued processing can cause the total number of error rows captured in the first error table to exceed the ErrorLimit specification.