Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Teradata RDBMS forUNIX SQL Reference - NCR

NCR Teradata RDBMS forUNIX SQL Reference - NCR, 1997. - 913 p.
Download (direct link): teradataforunix1997.pdf
Previous << 1 .. 40 41 42 43 44 45 < 46 > 47 48 49 50 51 52 .. 241 >> Next


Refer to the Glossary for a definition of SQL terminal symbols.

On a Japanese character supported site, the Teradata RDBMS validates all character data against the range of hexadecimal values considered valid for the character set of the current session.

All validated single byte character data is translated into the Teradata RDBMS internal representation, which is based on JIS-0x0201. See Appendix H, “Japanese Character Sets” and Appendix I, “Non-valid Japanese Character Code”, for the tables of character set encodings, translation mapping, and validation ranges.

Teradata RDBMS for UNIX SQL Reference

5-39
Data Definition

Character Data for a Japanese Character Supported Site

Translation and storage of validated multibyte character data depends on the character set of the current session, as explained in the following table.

Character Set How Multibyte Characters are Translated and Stored
KanjiEBCDIC All multibyte characters are stored as received; that is, they are not translated and remain in the client encoding. The Shift-Out and Shift-In characters are stored as part of the string after being translated to the same value (0E and 0F, respectively).
KanjiShift-JIS All multibyte characters are stored as received; that is, they remain in the client encoding.
KanjiEUC Multibyte character data is handled according to the client encoding of the current session, as follows

For each character of this code set . . . The first byte is translated as to. . .
cs1 KanjiShift-JIS (based on JIS-x0208), as illustrated in the translation map in Appendix H and I. Subsequent characters are also translated to KanjiShift-JIS.
cs2 0x80 and the second byte is left unmodified.
cs3 0xFF and the remaining two bytes are left unmodified.

5-40

Teradata RDBMS for UNIX SQL Reference
Data Definition

BYTE and VARBYTE Data Types

BYTE and VARBYTE Data Types

BYTE and VARBYTE are flagged as non-ANSI when the SQL flagger

Introduction 5 is enabled.

The BYTE data type represents a fixed-length binary string. The specification is:

^ BYTE^---------------1----

Lvarbyte J LnJ

HH01A097

If no value is specified for n, the default is BYTE(1).

Fixed Length Binary String

& J a BYTE (n)

n = 1 to 32000 (number of bytes) ffi9aoio

The BYTE data type is stored in the client system’s format; it is never translated by the Teradata RDBMS. BYTE data is handled as n-byte unsigned binary integers.

This data type is suitable for digitized images.

The VARBYTE(n) data type represents a variable length binary string.

The maximum length for n (BYTE and VARBYTE) is 32,000.

Variable Length Binary String

VARBYTE (n)

Two byte length

n = 1 to 32000 (maximum number of bytes) FFi9A0n

The VARBYTE data type is stored in the client system’s format; it is not translated. VARBYTE data is handled as n-byte unsigned binary integers.

This data type is suitable for digitized images.

The BYTE and VARBYTE(n) data types store raw data as logical bit streams. For any machine, BYTE data is transmitted directly from

Teradata RDBMS for UNIX SQL Reference

5-41
Data Definition

BYTE and VARBYTE Data Types

the client system’s memory. The sort order is logical, and values are compared as if they were n-byte, unsigned binary integers.

Logical bit streams are not translated. However, the interpretation of a hexadecimal string in EBCDIC form depends on the client system from which that string is submitted.

In the following example, BinaryData is assigned the VARBYTE(n) data type:

BinaryData VARBYTE(12),

5-42

Teradata RDBMS for UNIX SQL Reference
Data Definition

Japanese Character Graphic Data Types

Introduction

Japanese Character Graphic Data Types

Japanese character graphic data types are flagged as non-ANSI, when the SQL flagger is enabled.

On a Japanese character supported site, the following data types can be used to represent multibyte character data.

• GRAPHIC

• VARGRAPHIC

• LONG VARGRAPHIC

Each multibyte character in a graphic string is stored assuming two bytes per logical character. Therefore, a graphic data string must always represent an even multiple of bytes.

Graphic data types accommodate the following character sets:

• KanjiEBCDIC double byte graphic data

• KanjiShift-JIS for double byte Shift-JIS codes

• KanjiEUC for fixed-length, double byte EUC characters

Graphic columns also accept EUC codeset cs3 characters (three bytes per character) as long as the string contains an even multiple of cs3 characters (representing six bytes, twelve bytes, and so forth). However, this is not recommended because the correct manipulation of cs3 characters cannot be guaranteed.

Graphic columns also can be defined and populated under the standard EBCDIC and ASCII character sets, as long as it is Japanese character site.

Because graphic data types are available to all users regardless of their character set, special care must be taken when graphic data that was inserted under one character set is retrieved under a different character set. The data returned to the client might not be valid double byte characters for the character set of the current session.
Previous << 1 .. 40 41 42 43 44 45 < 46 > 47 48 49 50 51 52 .. 241 >> Next