RE: International Language Support Experiences?

Tanel,

You are correct except it is supported with 8i, make sure compatible parameter is set to 8.1.x.

-----Original Message-----
Sent: Wednesday, August 27, 2003 5:55 PM To: Multiple recipients of list ORACLE-L

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" <ORACLE-L_at_fatcity.com> 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
>
>
>
>
>
> john.kanagaraj_at_hds.com 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:dwagoner_at_arsenaldigital.com]
> > 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: davehau123_at_netscape.net
>
> 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: ListGuru_at_fatcity.com (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: tanel.poder.003_at_mail.ee

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: ListGuru_at_fatcity.com (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: Richard Ji
  INET: Richard.Ji_at_ztango.com

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: ListGuru_at_fatcity.com (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).