- ErrorTable1 (Acquisition Error Table) - Reports constraint violations, bad data, and data conversion errors.
- Error Table2 (Application Error Table) - Contains any rows that cause violations of the unique primary index, for instance duplicate rows.
The following operators support error tables:
|Load||Generates acquisition and
application error tables (ErrorTable1 and ErrorTable2).
Error tables are named in one of the following two ways:
|Stream||Generates only an acquisition error table
(ErrorTable), which is equivalent to ErrorTable1. The Stream
operator places the table in the database associated with the job
script user logon.
The error table is named in one of the following two ways:
The content and format of error tables is different for each of these operators. For detailed information the sections beginning with Load Operator Errors.
- If a job generates no errors, the error tables are empty. They are automatically dropped at the end of the job, unless the DropTable attribute is set to No.
- If errors are generated, error tables are retained at the end of a job.
- To rerun jobs from the beginning, either delete the associated error tables or rename them, otherwise an error message results, stating that the error tables already exist.
- Conversely, to restart a job from a step or checkpoint, an error table must already exist. Do not delete error tables until you are sure you will not have to restart the job.
- To reuse names specified for error tables, use the DROP TABLE statement in the BTEQ utility or the DDL operator to remove the tables from the Teradata Database.