Truncation Exceptions - Teradata Database

Fixed length columns are awkward to use in Kanji environments. The reason is that ANSI SQL treats fixed length strings in terms of characters, while most applications treat fixed length strings in terms of physical bytes. The difference cannot be reconciled.

Teradata SQL addresses this problem by treating LATIN, UNICODE and GRAPHIC character data type columns according to ANSI, but also providing the export width rules to export them as fixed byte length fields. For more information about export width, see “Working with Export Widths” on page 131.

Sharing the fixed length KANJISJIS server character set fields involves a different problem. The applications need to place enough padding within the field so that when it is converted to a different form-of-use, say KANJISJIS to KanjiEUC character set, the meaningful characters in the string are not truncated.

Truncation due to conversion and length change does not occur for KANJI1 server character set fields.

Because of the length change problem, you should use varying character fields when different representations can vary in length.

Truncation exceptions can occur for character data types during the following operations:

During external-to-internal conversion and assignment of USING data into a column with the SQL INSERT statement or using load utilities.

Explicit conversion using the SQL CAST or CHARACTER clauses.

On internal-to-external conversion of data exported to the client.

The behavior of the truncation depends upon whether the conversion occurs while the Teradata Database is operating in Teradata mode or ANSI mode. For more information, see “Truncation Exceptions in ANSI Mode” on page 144 and “Truncation Exceptions in Teradata Mode” on page 145.

In this mode …	Truncation of this server character set is as follows …
ANSI	non-pad character data causes an error.
Teradata	character data is truncated without reporting an error.