A character set specifies which characters are available (for example, whether the Japanese characters are available) and how those characters are represented (for example, EBCDIC or ASCII). Character data in logon strings, request data, response data, and error messages are affected by the choice of character set. An application can specify character sets; if the character set is not specified, the default from the HSHSPB or Teradata Database is used. After a character set is used for a request, it will continue to be used for subsequent requests in that session until another character set is specified.
Teradata Database processes strings from left to right, even for character sets associated with right-to-left or bidirectional languages, such as Hebrew or Arabic.
Allowing a default character set to be used will often cause the following problems in applications:
- Because the logon string and request data use the character set, if the default changes, so must the logon string or request data.
- Because the response data and error messages use the character set, an application that inspects this information must consider the character set. Such considerations might be minor (EBCDIC compared to EBCDIC277_0E) but they could be major (EBCDIC compared to UTF16). While the used character set might be obtained after a session is established (using the DBCHQE service's Session-character-set query), doing so is too late to ensure the logon string is in the proper character set. The application may obtain the default before establishing a connection using the DBCHQE service's Default-character-set query. After the default character set is known, the application could either reject its use or perform any character conversions necessary for its use.
If the TDPid is specified as a prefix to the logon string, then even if a Teradata Database default character set is acceptable to an application, it should be obtained and explicitly specified when the session is established. This is necessary because the database default character set cannot be known by CLIv2 until the TDPid is known, but to obtain the TDPid from the logon string requires the character set be known. If no character set is specified or defaulted using the HSHSPB, an attempt will be made to obtain the TDPid from the logon string using EBCDIC, which might not have the same characteristics as the database default character set. So the TDPid might not be found, the default TDPid from the HSHSPB used, and the wrong database might be assumed. Even if the default TDPid is the expected TDPid, the database will fail the attempt because CLIv2 cannot remove the TDPid prefix from the logon string.
Character sets can be supplied by the Teradata Database or defined by the customer. The names of all character sets supplied the Database are known to CLIv2. Character sets defined by the customer must also be defined to CLIv2. For more information, see User-Defined Character Sets.