For clients that do not support UTF8, you can set NLS_LANG on the client server to the appropriate single byte character set. The Oracle client library will do the conversion to/from UTF8 when you store/retrieve data to/from the Oracle server.

In fact, using UTF8 on the Oracle server does not require _any_ of your client apps to use UTF8 at all. Suppose you have an Oracle server at your corporate headquarters serving the needs of multiple client apps around the world. The app servers in Asia, Europe, Africa, S. America etc. can each set NLS_LANG to their own _single byte_ character set and still, because the Oracle server at corporate uses UTF8 which is MBCS, the app servers can all share the same Oracle server.

HTH,
Dave





[EMAIL PROTECTED] wrote:
David,
I can share this from an Oracle Apps perspective - we upgraded to UTF8 (a multi byte char set) from WE8ISO5599-1 (single byte Western Eur charset). Some of the biggest problems that we faced are:
1. Cut-and-paste produces incorrect characters which were acceptable in WE8 but failed conversion. I.e. UTF8 is stricter in what it can display as compared to WE8. This was pronounced in the umlaut and other Eur specific characters.
2. Quite a number of third-party applications do not support UTF8 - when asked about Unicode support, many vendors didn't even know what it would mean to support a MBCS such as UTF-8. This may also be the case with your own applications.
3. Middle-ware layers such as ODBC/JDBC don't work very well with UTF8 in the sense that the rules have become stricter and so programs that used to work previously will now fail mysteriously with vague messages (or worse still silently!).
4. A column which supports text elements that may now handle MBCs will require more storage width than previously designed for. Thus you may have to look at schema changes to increase VARCHAR2/CHAR columns..
5. Oracle products themselves may need some patches - you mention iAS - and have functional restrictions.
6. The
You won't hit 1 because you are moving from US7ASCII (7 bit) but watch out for the rest! ML Note 158577.1 is a good starting point. I would read this one (and the related links) before the 450 pages - you seem to like reading :)


John Kanagaraj
DB Soft Inc
Phone: 408-970-7002 (W)

Disappointment is inevitable, but Discouragement is optional!

** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers **



    -----Original Message-----
    From: David Wagoner [mailto:[EMAIL PROTECTED]
    Sent: Wednesday, August 27, 2003 11:35 AM
    To: Multiple recipients of list ORACLE-L
    Subject: International Language Support Experiences?

    We have a new requirement to support multiple languages in at least
    one of our databases.  I'm reading the Oracle 9iR2 Globalization
    Support Guide (450 pages), but wonder if any of you can share
    real-life experiences regarding:

    1.  the conversion of existing DBs to broader character sets
    2.  using Unicode
    3.  implementing this with 9iAS

    Our databases currently use US7ASCII with the American character
    set, but we will likely need to support European, Southeast Asian,
    and South American languages.


Thanks.



Best regards,


    David B. Wagoner
    Database Administrator
    Arsenal Digital Solutions



--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Dave Hau
 INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



Reply via email to