Teradata SQL Error and Failure Codes from Error 5553 To 5565

5553 The startup string is longer than permitted.
Explanation: The startup string cannot be longer than 255 characters.
Generated By: Parser (opd).
For Whom: END USER
Remedy: Use a shorter startup string.

5554 The startup value must be a character string.
Explanation: The startup value must be a character string.
Generated By: Parser (opd and opu).
For Whom: END USER
Remedy: Use a character string for the startup value.

5555 Excessively complex qualify condition.
Explanation: Possibly because of complex correlated subquery in the qualify clause or the query specified an OR condition
involving a subquery (Complex join) in the qualify clause.
Generated By: OPT
For Whom: User
Remedy: Rewrite the query.

5556 The comment string must be of type character.
Explanation: The comment string must be of type character.
Generated By: Parser (opd).
For Whom: END USER
Remedy: Use a character string for comment.

5558 Query capture limits exceeded for %VSTR.
Explanation: An internal limit in the Query Capture facility was exceeded
Generated By: PAR
For Whom: End User and System Support Representative.
Remedy: Save the query, and contact your support representative.

5559 The stored procedure version is invalid.
Explanation: The stored procedure version is not compatible with the Teradata RDBMS server release. It is either out
dated or not supported in the current Teradata system release. The version mismatch may be because the stored procedure
is created on a different version of the server and is being used in a server release where its behavior may be unpredictable.
Generated By: OPU Modules.
For Whom: End user.
Remedy: Recompile the stored procedure in the current Teradata system.

5560 Table names are mismatched in the UPSERT statement.
Explanation: The user specified two different tables in the UPDATE and INSERT parts of an UPSERT statement. The
same table must be referenced in both parts of an UPSERT statement, since the purpose of an UPSERT is to find a row or
rows to update, and if no row is found to insert a corresponding row into the table.
Generated By: Parser.
For Whom: End User.
Remedy: Correct the UPSERT statement and resubmit.

5561 The primary index values are mismatched in the UPSERT statement.
Explanation: The user specified different primary index values for the UPDATE and the INSERT parts of an UPSERT
statement. The same primary index values must be used in both parts of an UPSERT statement, since the purpose of an
UPSERT is to find a row or rows to update, and if no row is found to insert a corresponding row into the table.
Generated By: Parser.
For Whom: End User.
Remedy: Correct the UPSERT statement and resubmit.

5562 The UPDATE part of the UPSERT statement is not a single-AMP operation.
Explanation: The UPDATE part of the UPSERT statement is not a single-AMP operation, this could be due to one or
more of the following reasons:
1. The user did not fully specify the primary index in the UPDATE part of the UPSERT statement. The same fully specified primary index must be used on both the UPDATE and INSERT parts of an UPSERT statement, since the purpose of an UPSERT is to find a row or rows to update, and if no row is found to insert a corresponding row into the table.
2. The WHERE clause of the UPDATE part of the UPSERT statement compares the fully specified primary index against
another field of the same table. This results in an all-AMP update.
3. The WHERE clause of the UPDATE part of the UPSERT statement compares the fully specified primary index against
some value using a non-equality constraint. This also results in an all-AMP update.
4. The WHERE clause of the UPDATE part of the UPSERT statement compares the fully specified primary index with an
operand of a different data type. This could cause the system to convert the primary index values to match the data type of the operand and thus result in an all-AMP update.
Generated By: Parser.
For Whom: End User.
Remedy: Correct the UPSERT statement and resubmit.

5565 The UPDATE specified in the UPSERT statement is a complex update.
Explanation: The user specified the UPDATE in the UPSERT statement as a complex update. Examples of complex
update are UPDATEs that change the primary index value or the value of a partitioning column, UPDATEs that have subquery, and UPDATEs from another table. Only simple prime-key UPDATEs are allowed in UPSERTs. OR The user gave
UPSERT query on a Normalize Table //DR153359-sk186018-01
Generated By: Parser.
For Whom: End User.
Remedy: Correct the UPSERT statement and resubmit.

Above are list of Teradata Errors or Failure Codes from Error 5553 To 5565 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 *