UTF8 or VarGraphic?
Ionut Filip
server and oracle.
It's supposed to have unicode support. (To be fair, I don;t know much about
this)
Now, in SQL Server we use nvarchar, ntext etc for the column types. I'm not
sure if this question makes sense, but what are my options in db2 - use the
vargraphic column types (I'm worried about what string functions are
available for them) or just use plain varchar columns and instruct the users
to use a utf8 character set.
thanks!
Serge Rielau
AFAIK VARGRAPHIC matches nvarchar, DBCLOB matches ntext.
Starting in V7 FP3 (I think) char types and graphic types ar eequivalent and
most functions that exist for char also exist for graphic. If a given fucntion
doesn't exist in teh fixpack you use it will be soon and you can simply cast the
graphic to char before applying the respective char function.
So far so good... Now UTF-8 has mixed length. I.e. VARCHAR(12) can hold anywhere
between 4 and 12 characters. The length function returns the byte length and
substr() also uses bytes.
With VARGRAPHIC(6) you know you can fir 6 characters. LENGH returns length in
characters and substr() also uses character positions.
Cheers
Serge
--
Serge Rielau
DB2 UDB SQL Compiler Development
IBM Software Lab, Canada
Ionut Filip
Siddharth Aggarwal
I faced a similar problem like yours and this is how I went about it. I had
to connect a unicode application to a DB2 database using DB2 CLI. Now a DB2
database can be either unicode or non-unicode. This really doesn't matter
when you are using vargraphic columns because data in such columns is stored
as UCS-2. i.e. irrespective of the database encoding, a VARGRAPHIC(10)
column can hold only 5 characters. However if you use a VARCHAR(10) column,
and if your database is Unicode, you could store only 3 Japanese characters
(i.e. in UTF8 encoding each Japanese character requires 3 bytes). The same
column when created in a localised database e.g. JA16SJIS encoding, you can
store upto 5 Japanese characters(in JA16SJIS each Japanese character
requires 2 bytes). So your application must take care of this when data is
being retrieved i.e. if the codepage of your application is UTF8, then you
will be able to get only 3 characters from the VARCHAR(10) column even
though it contains 3 Japanese characters. This truncation occurs because of
the known limitation of DB2 that you cannot connect a UTF8 client (your
application) to a non-unicode database. Hence for this to behave correctly,
your application must have a JA16SJIS codepage. This however compromises on
the flexibility of your application as you need to change the codepage of
your application each time you connect to a differently encoded database.
This doesn't happen in Oracle8i upwards. You can set your application to
UTF8 and all conversions are done automatically.
To have the maximum benefit, I would suggest that your application should
support correct behaviour in both options you have pointed out i.e.
1. vargraphic columns
2. varchar with UTF8/nonUTF8 i.e. simply means unicode and non unicode
databases
Hope this helps.
Regards,
Siddharth.
"Ionut Filip" <io...@tariansoftware.com> wrote in message
news:MJmq8.9948$f5.723137@news...