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);
The USING request modifier indicates that the data parcel contains the following:
- 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.
Stage | Process | |||
---|---|---|---|---|
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.