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 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 241 >> Next


Also, two different character sets might have the same internal encoding for two logically different multibyte characters. Thus, two names might compare as identical even if their logical meanings are different.

The Teradata RDBMS knows an object name by its internal hexadecimal representation, and this is how a name is stored in the various system tables of the Data Dictionary. As discussed in the previous passages, the encoding of a name’s internal representation depends on the components of the name string (single byte characters and/or multibyte characters, with or without Shift Out/Shift In (SO/SI) characters) and the character set in effect when the name was created.

Teradata RDBMS for UNIX SQL Reference

4-15
Teradata SQL Lexicon

Object Name Comparisons

Example

Assume that a user under one character set needs to reference a name created by a user under a different character set. If the current user attempts to reference the name with the actual characters (that is, by typing the ideographs or by selecting non-specific entries from a dictionary table), the access could fail or the returned name could be meaningless.

For example, assume that User1 invokes a session under KanjiEBCDIC and creates Tname with multibyte characters. If User2 invokes a session under KanjiEUC and issues the statement SELECT Tname FROM DBC.Tables, User2 will receive the KanjiEBCDIC characters in KanjiEUC presentation, which probably would not make sense.

You can avoid this condition in the following ways.

• You can create names using only simple single byte Latin letters (A...Z, a...z) digits, and the dollar sign, pound sign, and underscore symbols.

Because these characters always translate to the same internal representation, they display exactly the same presentation to any session, regardless of the client or the character set.

• You can always reference a name by its internal representation, using the following form:

'hexadecimal_digit(s)'---XN--------

HH01A099

where:

'hexadecimal_digits ’ is the quoted hexadecimal string of the Teradata RDBMS internal encoding.

The key letters XN specify that the string is a hexadecimal name.

The following table name, which contains mixed single byte characters and multibyte characters, was created under a KanjiEBCDIC character set:

<TAB1>KAN

The client encoding in which this name was received is as follows:

0E 42E3 42C1 42C2 42F1 0F D2 C1 D5

< T A B 1>K AN

The single byte characters (the letters K, A, and N, and the SO/SI characters) were translated into internal JIS-x0201 encoding. The multibyte characters were not translated and remained in the host encoding.

4-16

Teradata RDBMS for UNIX SQL Reference
Teradata SQL Lexicon

Object Name Comparisons

The resulting internal string by which the name was stored is as follows:

0E 42E3 42C1 42C2 42F1 0F 4B 41 4E

< T A B 1> K A N

To access this table from a KanjiShift-JIS or KanjiEUC character set, you could use the following Teradata SQL statement:

SELECT * FROM '0E42E342C142C242F10F4B414E'XN;

The response would be all rows from table <TAB1>KAN.

Teradata RDBMS for UNIX SQL Reference

4-17
Teradata SQL Lexicon

Finding the Internal Hexadecimal Representation of a Name

Finding the Internal Hexadecimal Representation of a Name

The CHAR2HEXINT function converts a character string to its Introduction 4 internal hexadecimal representation. You can use this function to

find the internal representation of any Teradata RDBMS name.

Example 1

For example, to find the internal representation of all Teradata RDBMS table names, issue the following Teradata SQL statement:

SELECT

CHAR2HEXINT(T.TableName)

(TITLE 'Internal Hex Representation of TableName')

, T.TableName (TITLE 'TableName')

FROM DBC.Tables T WHERE T.TableKind = 'T'

ORDER BY T.TableName;

This statement selects from the DBC.Tables view all rows where the value of the TableKind field is T. For each row selected, it returns both the internal hexadecimal representation and the character format of the value in the TableName field. The rows are sorted alphabetically.

An example of a portion of the output from this statement is shown below. In this example, the first name (double byte-A) was created using the KanjiEBCDIC character set.

Internal Hex Representation of TableName TableName

0E42C10F2020202020202020202020202020202020202020202020202020 4163 63 6573 7352 6967687473202020202020202020202020202020202020 AccessRights 4163634C6F6752756C6554626C2020202020202020202020202020202020 AccLogRuleTb 4163634C6F6754626C202020202020202020202020202020202020202020 AccLogTbl 4163636F756E747320202020202020202020202020202020202020202020 Accounts 416363746720202020202020202020202020202020202020202020202020 Acctg 416C6C202020202020202020202020202020202020202020202020202020 All 43 68616E67656452 6F774A6F7572 6E616C20202020202020202020202020 ChangedRowJo 63 6 8 65 63 6B5F70 65 72 6D2 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 0 check_perm 436F70496E666F54626C2020202020202020202020202020202020202020 CopInfoTbl
Previous << 1 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 241 >> Next