The Update operator provides the same capability as the Load operator for setting an approximate number of errors captured before a job is terminated. The number is approximate because the Update operator sends multiple rows of data at a time to the Teradata Database. By the time the Update operator processes the message indicating that the error limit has been exceeded, the operator may have loaded more records into the error table than the actual number specified by the error limit.
When updating large amounts of data, it is not uncommon to encounter a data error that occurs repeatedly on each input record. Because an error can often be corrected long before errors are generated for all the records in a job run, consider using the ErrorLimit attribute to specify an approximate number of errors that can be tolerated before a job is terminated.
Note that the ET table contains errors in rows detected during the acquisition phase (the loading of data). These are commonly data conversion errors. The second table is the UV table and contains rows that are detected to be in error during the application phase of the job. These errors are commonly “uniqueness violation” errors (hence the name UV).
The ErrorLimit specification applies to each instance of the Update operator, not to all instances combined. For example, if the limit is set to 1,000, a single instance must detect that 1,000 rows were inserted into error tables to terminate the job.
This limit is specified with the ErrorLimit attribute. Errors are counted only during the Acquisition Phase, so the number of error rows being placed in the ET table are counted towards the number set in the ErrorLimit attribute. This applies to each instance of the Update operator, not to all instances combined. Therefore, if an error limit is set to 1,000, a single load instance must detect that 1,000 rows are inserted into the error tables before the job is terminated.
The error limit can also be reached at checkpoint time. See the examples below.