Re: DB2:Graphic(n) vs Oracle:nvarchar2 Datentyp


[ ruban.de ] [ Antworten ] [ Forum ]

Geschrieben von Gernot Ruban on Juli 09, 2002 um 17:21:

Als Antwort auf DB2:Graphic(n) vs Oracle:nvarchar2 Datentyp geschrieben von Volker Biedermann on Juli 01, 2002 um 17:32:

Hi Volker,

hier ein Auszug aus dem Release Notes DB2 V7.2 Fixpak 7 (in Kürze auch für Win und OS/2 verfügbar).
Gruß
Gernot

Literals in Unicode Databases

In non-unicode databases, data in LONG VARGRAPHIC and LONG VARCHAR columns cannot be compared. Data in GRAPHIC/VARGRAPHIC and CHAR/VARCHAR columns can only be compared, or assigned to each other, using explicit cast functions since no implicit code page conversion is supported. This includes GRAPHIC/VARGRAPHIC and CHAR/VARCHAR literals where a GRAPHIC/VARGRAPHIC literal is differentiated from a CHAR/VARCHAR literal by a G prefix.
For Unicode databases, casting between GRAPHIC/VARGRAPHIC and CHAR/VARCHAR literals is not required.
Also, a G prefix is not required in
front of a GRAPHIC/VARGRAPHIC literal. Provided at least one of the arguments is a literal, implicit conversions occur. This allows literals with or without the G prefix to be used within statements that use either SQLPrepareW() or SQLExecDirect(). Literals for LONG VARGRAPHICs still must have a G prefix.

For more information, see ″Casting Between Data Types″ in ″Chapter 3. Language Elements″ of the SQL Reference.


Other points to consider when using Unicode:

1. The database code page is determined at the time the database is created, and by default its value is determined from the operating system locale (or
code page). The CODESET and TERRITORY keywords can be used to explicitly create a Unicode DB2 database. For example: CREATE DATABASE unidb USING CODESET UTF-8 TERRITORY US
2. The application code page also defaults to the local code page, but this can be overridden by UTF-8 in one of two ways:
- Setting the application code page to UTF-8 (1208) with this command: db2set DB2CODEPAGE=1208
- For CLI/ODBC applications, by calling SQLSetConnectAttr() and setting the SQL_ATTR_ANSI_APP to SQL_AA_FALSE. The default setting is SQL_AA_TRUE.
3. Data in GRAPHIC columns will take exactly two bytes for each Unicode character, whereas data in CHAR columns will take from 1 to 3 bytes for each Unicode character. SQL limits in terms of characters for GRAPHIC columns are generally half of those as for CHAR columns, but they are equal in terms of bytes. For example, the maximum character length for a
CHAR column is 254, and the maximum character length for a graphic column is 127. For more information, see MAX in the ″Functions″ chapter of the SQL Reference.
4. A graphic literal is differentiated from a character literal by a G prefix. For example:
SELECT * FROM mytable WHERE mychar = ’utf-8 data’
AND mygraphic = G’ucs-2 data’
Note: The G prefix is optional for Unicode databases.
See “Literals in Unicode Databases” on page 319 for more information and updated support.
5. Support for CLI/ODBC and JDBC applications differ from the support for Embedded applications. For information specific to CLI/ODBC support,
see “CLI Guide and Reference” on page 313.
6. The byte ordering of UCS-2 data may differ between platforms. Internally, DB2 uses big-endian format.



Antworten:


Schreibe eine Antwort

Name:   
E-Mail:  

Thema:

Kommentar:

Optionale Link URL:   
Link Titel:                  
Optionale Image URL:


[ Antworten ] [ Forum ]