data_type Considerations for a Japanese Character Site - Teradata Database - Teradata Vantage NewSQL Engine

SQL Data Manipulation Language

Product
Teradata Database
Teradata Vantage NewSQL Engine
Release Number
16.20
Published
March 2019
Language
English (United States)
Last Update
2019-05-03
dita:mapPath
fbo1512081269404.ditamap
dita:ditavalPath
TD_DBS_16_20_Update1.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.