Consider the following table definition:
CREATE TABLE table_1 ( cunicode CHARACTER(10) CHARACTER SET UNICODE, clatin CHARACTER(10) CHARACTER SET LATIN, csjis CHARACTER(10) CHARACTER SET KANJISJIS, cgraphic CHARACTER(10) CHARACTER SET GRAPHIC, cgraphic2 CHARACTER(10) CHARACTER SET GRAPHIC);
Suppose the session character set is KanjiShift-JIS and you submit the following request:
USING cunicode (CHARACTER(10)), clatin (CHARACTER(10)), csjis (CHARACTER(10)), cgraphic (GRAPHIC(10)), cgraphic2 (CHARACTER(10) CHARACTER SET GRAPHIC)) INSERT INTO table_1(:cunicode, :clatin, :csjis, :cgraphic, :cgraphic2);
- 10 KanjiShift-JIS bytes for the Unicode column
- 10 bytes for the Latin column
- 10 bytes for the KanjiSJIS column
- 20 bytes for the first GRAPHIC column
- 20 bytes for the second GRAPHIC column
Individual fields in the data parcel are converted from the client form-of-use to the server form-of-use. After conversion, the first three fields are treated as Unicode literals and the last two fields are treated as GRAPHIC literals (see Teradata Vantage™ - Data Types and Literals, B035-1143).
The column data is then converted to the target fields using implicit translation according to the rules listed in Teradata Vantage™ - Data Types and Literals, B035-1143.
The conversion process is described by the following table.
|These bytes are converted to server form-of-use …||Treated as this kind of literal …||Converted to this character data type …||And stored in this column …|
|1||first 10 (1 - 10)||UNICODE||none||cunicode|
|2||next 10 (11 - 20)||UNICODE||LATIN||clatin|
|3||next 10 (21-30)||UNICODE||KANJISJIS||csjis|
|4||next 20 (31 - 50)||GRAPHIC||GRAPHIC||cgraphic|
|5||last 20 (51 - 70)||GRAPHIC||GRAPHIC||cgraphic2|
Note that the meaning of the USING clause is independent of the session character set.