Comparison of KANJI1 Characters - Teradata Database

Comparison of KANJI1 Characters

The following sections describe how Teradata Database compares KANJI1 characters.

Caution:

In accordance with Teradata internationalization plans, KANJI1 support is deprecated and is to be discontinued in the near future. KANJI1 is not allowed as a default character set; the system changes the KANJI1 default character set to the UNICODE character set. Creation of new KANJI1 objects is highly restricted. Although many KANJI1 queries and applications may continue to operate, sites using KANJI1 should convert to another character set as soon as possible. “”

Equality Comparison

Comparison of character strings, which can contain mixed single byte and multibyte character data, is handled as follows:

If expression_1 and expression_2 have different server character sets, then they are converted to the same type. For details, see “Implicit Character-to-Character Translation” on page 603.

If expression_1 and expression_2 are of different lengths, the shorter string is padded with enough pad characters to make both the same length.

Session mode is identified:

In this mode …	The default case specification for a character string is …
ANSI	CASESPECIFIC.
Teradata	NOT CASESPECIFIC. Unless the CASESPECIFIC phrase is applied to one or both of the expressions, any simple Latin letters in both expression_1 and expression_2 are converted to uppercase before comparison begins.

To override the default case specification of a character expression, apply the CASESPECIFIC or NOT CASESPECIFIC phrase.

Case specification is determined:

IF …	THEN the comparison is …
either argument is CASESPECIFIC	case specific.
both arguments are NOT CASESPECIFIC	case blind.

Trailing pad characters are ignored.

Nonequality Comparison

Nonequality comparisons are handled as follows:

1 If expression_1 and expression_2 are of different lengths, the shorter string is padded with enough pad characters to make both the same length.

2 Session mode is identified.

In this mode …	The default case specification for a character string is …
ANSI	CASESPECIFIC.
Teradata	NOT CASESPECIFIC. Unless the CASESPECIFIC qualifier is applied to one or both of the expressions, any simple Latin letters in both expression_1 and expression_2 are converted to uppercase before comparison begins.

To override the default case specification of a character expression, apply the CASESPECIFIC or NOT CASESPECIFIC phrase.

3 Characters identified as single byte characters under the current character set are converted according to the collation sequence in effect for the session.

4 For the KanjiEUC character set, the ss3 0x8F character is converted to 0xFF. This means that a user-defined KanjiEUC codeset 3 is not properly ordered with respect to other KanjiEUC code sets.

The ordering of other KanjiEUC codesets is proper; that is, ordering is the same as the binary ordering on the client system.

5 The prepared strings are compared and trailing pad characters are ignored.

Nonequality comparisons involve the collation in effect for the session. Five collations are available:

EBCDIC

ASCII

MULTINATIONAL

CHARSET_COLL

JIS_COLL

Collation can be set at the user level with the COLLATION option of the CREATE USER or MODIFY USER statements, and at the session level with the [[.]SET] SESSION COLLATION statement or the CLIv2 CHARSET call.

If the MULTINATIONAL collation sequence is in effect, the collation sequence of a Japanese language site is determined by the collation setting installed during start-up.

For further details on collation sequences, see International Character Set Support.