data_type Considerations for a Japanese Character Site - Advanced SQL Engine - Teradata Database

SQL Data Manipulation Language

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
vjt1596846980081.ditamap
dita:ditavalPath
vjt1596846980081.ditaval
dita:id
B035-1146
lifecycle
previous
Product Category
Teradata Vantageā„¢

Be very careful with Japanese character data regarding the information that will be sent in the data parcel in client form-of-use. Consider the following example for illustrating the issues involved.

     USING (emp_name   CHARACTER(40) UPPERCASE,
            emp_number INTEGER)
     INSERT INTO employee (:emp_name, :emp_number);

This request specifies that the data parcel contains 40 bytes of CHARACTER data for emp_name and four bytes of INTEGER data for emp_number.

Because the data_type describes the layout of the data parcel in terms of client form-of-use, this means that CHARACTER(40) indicates 40 bytes of CHARACTER information rather than 40 characters.

For single-byte character external data sets such as ASCII and EBCDIC, bytes and characters represent the same byte count.

For character sets containing mixed single-byte and multibyte characters (such as KanjiEUC), or only 2-byte characters, however, the numbers of bytes and numbers of characters are not identical.

Notice that the GRAPHIC and VARGRAPHIC data types have character counts that are always half the number of bytes.

For Kanji character sets containing only GRAPHIC multibyte characters, such as KanjiEBCDIC, character and byte units are identical.

You can specify GRAPHIC USING data by specifying a [VAR]CHAR(n) CHARACTER SET GRAPHIC attribute for the data_type. This is identical to specifying the data_type as [VAR]GRAPHIC(n).

There is no equivalent extension to CHARACTER SET syntax to account for CHARACTER data, because the data is in client rather than internal form-of-use.