Archives of the TeradataForum

Message Posted: Wed, 02 Mar 2005 @ 20:00:12 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

I am forwarding this response from Teradata software engineer Gary Roberts, who is a subject matter expert on Unicode:

Teradata is designed for seamless support of Unicode and non-Unicode applications, so coexistance should not be the issue, so long as data has always been entered with the correct session character set. Using the correct session character set (for perfectly valid reasons) may not be done for the current applications, and this can be problematic.

The Teradata DBS allows the user to determine the storage attributes (Unicode or non-Unicode) at the column level, and provides a uniform interface for applications based upon the session character set.

Not all client utilities support Unicode in a useful way, so it is important to know which clients are required to access the database. There are several forms of Unicode (UTF-16/UCS-2, UTF-8). The form of Unicode will affect the client utilities that can be used. All of the client utilities have fair support for UTF-8, but UTF-8 is poorly supported by Windows, so, it is often impractical to use UTF-8 clients on a Windows operating system.

That is general information, but I'm afraid the difficult issues will arrise in the detail. Unicode support in Teradata is improving, and so the release being used will play a factor. Unicode columns could be created on the database as far back as v2R3.0, but Unicode sessions came in later (UTF-8 in v2r4.1 and UTF-16 in v2r5.1, I believe). However, client support for UTF-16 was minimal for TTU 7.1. TTU 8.0 increased that support, particularly for ODBC.

	<Prev	Next>		<<First	<Prev	Next>	Last>>