Error Tables - Parallel Transporter

Teradata Parallel Transporter Application Programming Interface Programmer Guide

Product
Parallel Transporter
Release Number
16.10
Published
May 2017
Language
English (United States)
Last Update
2018-05-15
dita:mapPath
pev1488824663354.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2516
lifecycle
previous
Product Category
Teradata Tools and Utilities

The Update driver uses two error tables for each target table:

Update Driver Error Tables 
Error Table Contents
ErrorTable1 = et1name Records rejected because of:
  • Data conversion errors
  • Constraint violations
  • AMP configuration changes
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 Teradata Database at the end of an Update driver job. Use the DROP TABLE statement from BTEQ to remove the tables from the Teradata 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.

Update Driver ERRORLIMIT Values 
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.