IIRC, you can't store LOBs in UTF8 since it's a variable width charset? Tanel.
----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, August 27, 2003 11:59 PM > 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). > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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).
