The following table supplies additional usage considerations for Error Table information beyond that listed in System-Defined Attributes for Error Table-Specific Columns.
Column | Usage Notes |
---|---|
ETC_DBQL_QID | The system sets up a time-based query ID regardless of whether DBQL is enabled, and increments the ID for each new request. You can use the column ETC_DBQL_QID to uniquely identify all error rows for a request, but this approach is less reliable, because in a restart, the session numbers begin incrementing from the same base value. Therefore, two different requests may have the same host, session, and request numbers if there are restarts. |
ETC_ErrSeq | You can use ETC_ErrSeq column to determine the order of row updates and inserts for a MERGE operation. ETC_ErrSeq provides a numeric sequencing that is easier to refer to for error analysis and recovery purposes than the timestamps in ETC_TimeStamp. |
If the data row size plus the fixed error table columns exceeds the system row size limit, an ANSI session mode request aborts and returns an error message to the requestor, while a Teradata session mode transaction containing the erring CREATE ERROR TABLE request aborts and returns an error message to the requestor.
Using Error Table Data to Isolate Problems
Use the following general procedure to isolate problems using error table data:
- Query the error table to retrieve information on the errors logged for a user in an error table named ET_t and the DBQL query ID returned in the error or warning message:
SELECT ETC_ErrorCode, FieldName, ETC_IndexNumber, ETC_IdxErrType FROM ET_t, DBC.Tables3VX WHERE ETC_DBQL_QID = 123456789012345678 AND ETC_TableID = TableID;
- Look at each error code and column value related to the error and determine if any action must be taken.
- ETC_RowId
- ETC_ErrSeq