UTF8 and UTF16 Limitations
Limitations imposed for UTF8 and UTF16 are:
There may be unexpected (larger) string lengths when retrieving Unicode character
columns in the UTF8 or UTF16 session character set.
The UTF8 session character set may cause up to a three-fold expansion of character
data, which may cause a given row size to exceed the internal Teradata 64K row size
limit.
The UTF16 session character set may cause up to a two-fold expansion of character
data which may cause a given row size to exceed the internal Teradata 64K row size
limit.
Teradata SQL limitations in UTF8 and UTF16 may prevent the reference of Kanji based
objects in UTF8 or UTF16 session character sets.
Error messages from Teradata in UTF8 or UTF16 are returned in English. This may cause
some confusion, since provider based error messages may return in Japanese on Japanese
client systems.
Users should be aware of limitations in DBTYPE_WSTR if the selected Teradata session
character set is not Unicode-based (UTF8 or UTF16). If a character cannot be translated
to the Teradata session character set, a default character will be inserted in its
place. This translation can cause undesired corruption of data. For users who have
this kind of data, application, or environment, it is recommended that the user utilize
the UTF8 or UTF16 Teradata session character set.
Users should be aware of limitations in DBTYPE_STR if the selected Teradata session
character set is not Unicode based (UTF8 or UTF16), or the local code page does not
match the selected Teradata session character set. In this scenario, if certain characters
do not map between the local code page and the Teradata session character set, it
will be replaced with a default character. This translation can cause undesired corruption
of data. For users who have this type of environment, it is recommended that the user
utilize the UTF8 or UTF16 Teradata session character set.