Unicode Data in SQL server
tzh...@eds.com
Hi,
I need to support graphical languages like Chinese, Japanese... on
MS-SQLserver.
We are considering UNICODE format to store the data in the server. I was told
by MS Technical
group that MS SQLserver 6.0 or 6.5 will not support "UNICODE".
I need to find out how I can convert the data from unicode and display it in
windows or
ISQL/W in graphical format.
Is there any third party software available?
What type of querying can I do on this data?
Thanks..
Kasturi
Stefan Buchta
I would suggest that you look for a UNICODE-enabled DBMS to solve your
problem. That DBMS will do the translation between asian locales (Japaese,
Korean, Chinese etc.) to UNICODE automatically for you. Also all the
SQL-functions will work on UNICODE-data which will make building your
applications a lot easier. Asian locales come in many variations (see
my article on comp.software.international) and if you have to take care
of the translation between the many variations of for example Japanese
Shift-JIS locales BY YOURSELF you will take much longer designing your
application.
Please mail me personally if you want information about databases that
support UNICODE and the level of UNICODE-support. If you are interested
you could join a beta-test.
Stefan Buchta
Software AG of Far East/Tokyo
------------------------------------------------------------------------
Here are some facts about UNICODE and RDBMS:
-true UNICODE-support in an RDBMS means:
1. all UNICODE-data handled as UCS-2. (no internal usage of UTF-x-formats)
2. SQL-functions and aggregates work on UNICODE-datatype as well as
between UNICODE- and ASCII-datatypes.
3. transparent translation between different locales (asian, european)
on client- or server-side
- enabling UNICODE in a RDBMS is very painful. It means changing the
fundamental data-structures, changing the way components talk to the
DBMS-kernel, changing just about everything.
- a database vendor who offers you UNICODE-support must have reworked
about 70-80 % !!! of it愀 source-code to make it work for UNICODE.
That is one of the reasons why there are NO databases that support
true UNICODE at the moment.
- UNICODE comes in several representations (or formats): UCS-2, UTF-7,
UTF-8. Be careful if a vendor claims to support UTF-x internally.
Those formats are "compressed" versions of UNICODE that:
- are not usable for far-east-markets (they are not efficient, Kanji
will be stored as three bytes or they use shift-in shift-out
sequences etc, SQL-functions on those datatypes do not perform well)
- a database is UNICODE enables if it supports UCS-2 only
--
s...@sql.de