Teradata SQL Error and Failure Codes from Error 8274 To 8282

8274 TriggerCount field for table(s) is reset to zero.
Explanation: TriggerCount field in TVM row is reset to zero for the tables that are copied using ARC/COPY command.
But there could be trigger(s) defined in other databases having subject table as the table being copied. This can happen
when a table is copied back without dropping or a database is copied back without deleting. So this is a warning for the
end-user to drop the existing trigger(s) defined on the table(s) before creating a new one.
Generated By: Hut Insert Row procedure DoRowInsert
For Whom: ASF2/ARC to be displayed to End User.
Remedy: Need to drop the triggers defined for the table(s) copied using ARC/COPY operation, before creating new trigger(
s). For a table level copy operation, get the triggers information from dbc.triggerstbl by matching the tableid. For a
database level copy operation, get the triggers information from dbc.triggerstbl by matching subjecttabdbaseid.

8275 Restore/Copy Dictionary stopped because table definition is inconsistent between the
backup and disk.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because there is a
mismatch in DBC.TVM between one or more of the following table components on the dictionary backup and the entry on
disk. The fields checked for consistency are: – No entry for the DataBaseId/TVMNameI in DBC.TVM on disk – TableId –
TVMName – TableKind
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User.
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes.

8276 Restore/Copy Dictionary stopped because a significant change has occurred to the table
since creation of the backup.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because a significant
DDL change was applied to the table that is not reflected in the dictionary backup. This is detected by a mismatch in the
DBC.TVM UtilVersion field of the dictionary backup and the entry on disk when these are both non-zero or, if they are both
zero, a mismatch between the DBC.TVM Version field of the dictionary backup and the entry on disk. When non-zero, the
UtilVersion is the highest version number of the table structure when a significant DDL change occurred.
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes. – Identify DDL changes that have been applied to
the table since the backup.

8277 Restore/Copy Dictionary stopped because DBC.DBCASSOCIATION is inconsistent between
the backup and disk.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because there is a
mismatch in one or more of the following components in DBC.DBCASSOCIATION between the dictionary backup and the
entry on disk. The components checked for consistency are: – No entry for the TVMId in DBC.DBCASSOCIATION on disk
– Original_DatabaseName – Original_DataBaseId – Original_TVMNameI – Original_LogicalHostId – Original_TVMId –
Original_TableKind – Original_TVMName – Original_UtilVersion
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes.

8278 Restore/Copy Dictionary stopped because table’s column definitions are inconsistent
between the backup and disk.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because there is a
mismatch in one or more of the following components in DBC.TVFIELDS between the dictionary backup and the entry on
disk. The components checked for consistency are: – No entry for the TableId in DBC.DBCTVFIELDS on disk – FieldName –
FieldId – FieldType – MaxLength – DefaultValue – DefaultValueI – TotalDigits – DatabaseId – Compressible – CompressValue
– CompressValueList – Entries on disk and not present on the backup – Entries on the backup and not present on disk
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes.

8279 Restore/Copy Dictionary stopped because table’s primary index is inconsistent between the
backup and disk.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because there is a
mismatch in one or more of the following primary index components in DBC.INDEXES between the dictionary backup
and the entry on disk. The components checked for consistency are: – No entry for the TableId in DBC.INDEXES on disk. –
TableId – IndexNumber – UniqueFlag – FieldId – FieldPosition – IndexMode – DatabaseId
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes.

8280 Restore/Copy Dictionary stopped because an IDENTITY column is inconsistent between the
backup and disk.
Explanation: The restore/copy dictionary request for selected partitions of a PPI table was stopped because there is a
mismatch in one or more of the following components in DBC.IDCOL between the dictionary backup and the associated
entry on disk. The components checked for consistency are: – No entry for the TableId in DBC.IDCOL on disk when there is
an entry on the backup – DatabaseId – TableId/DatabaseId entry exists on disk but not on the backup
Generated By: Insert dictionary rows during restore step (hutinr)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct dictionary backup was specified. – Verify that a dictionary
restore was performed successfully following significant DDL changes.

8281 PPI RANGE mismatch between the table header and the HUT control segment.
Explanation: The current PPI range restore operation request (located in the HUT control segment) is different from the
restore operation in progress (as indicated in the tabled header). There is a mismatch in the PPI ranges.
Generated By: Restore data block host utility step (hutdtb)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct table restore job was restarted. – Verify that only 1 restore job
is running concurrently for a given table.

8282 Restore of selected partitions of a PPI table stopped because the table header is inconsistent
between the backup and disk.
Explanation: The restore request for selected partitions of a PPI table was stopped because there is a mismatch in one or
more components in field1 and field 5 of the table header on the backup and the table header on disk. The components checked for consistency are: – No table header on disk – formatversion – databaseid – structversion – utilversion – permjrnltbloid
– tablekind – hashedtable – ddlchange – primarykeyidxid – rowformat
Generated By: Restore data block (hutrdb)
For Whom: End User
Remedy: Corrective actions include: – Verify that the correct restore was specified. – Verify that a table backup was performed
successfully following significant DDL changes. – Run checktable utility at level 3 to identify possible table corruption.

Above are list of Teradata Errors or Failure Codes from Error 8274 To 8282 received while performing certain operation against Teradata Database or related products.

What are Teradata Database Errors?

In general, each Teradata error message contains the following information:
• The message number.
• The message text. This text is usually returned with the message number. Some messages employ word substitution, where the word substituted represents the system-replacement of a term more specific to the occurrence.
• An explanation of how the error may have occurred.
• Generated-by text that indicates the software module which initiated the message. This field serves a diagnostic purpose for support and development personnel.
• A remedy which suggests how to resolve the condition.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Teradata SQL Error and Failure Codes and Error Messages on Windows, Linux Operating Systems.

 

Leave a Reply

Your email address will not be published. Required fields are marked *