Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: NLS functionality and replication between different character encoding schemes

Re: NLS functionality and replication between different character encoding schemes

From: Sybrand Bakker <sybrand.bakker_at_bentley.nl>
Date: 1997/11/13
Message-ID: <346AEC81.D8246ABC@bentley.nl>#1/1

Working in an international firm myself (American/European) there is one initial rule to whatever you want to setup: downwards conversion (ie from 8-bit to 7-bit) is always impossible. This means in our case both databases had to be created in the 8-bit european character set you already specified, whether or not the Americas database will operate in US7ASCII. In your case all databases have to be created in the multibyte Japanese characterset, however in the European(?) case, either the NLS_LANGUAGE parameter of the client (infeasible) or of the server needs to be specified as we8 etc. According to Oracle conversion should be automatic across database links, however the restriction outlined above of course applies. In your case, I would create all databases in a multibyte character set.

Then it might be important to avoid using the default date format of DD-MON-YYYY (especially if you plan to run in multiple languages) and always use something like 'DD-MM-YYYY'. Somewhere in the Oracle 6 era, Oracle changed the default date format for the dutch language and we had to change about everything. You should never rely on the default date format.

One other showstopper, and so far we have been unable to resolve it: in our case it is important that our end-users don't have to know where the diacritical characters are. So far we have been unable to translate diacritical characters back to their non-diacritical equivalents, as there doesn't seem to be any native oracle sql function to support that. Of course setting up a translation table is an option, however for performance sake that is bad of course.

Then, as far as I know, the final one: as soon as you use a non-us nls_language setting, you are automatically using a translated message library. It happens quite frequently these libraries are either missing (ie have not been translated at all) or are incomplete.

Getting this working properly can be a real challenge!

Hope to have been of any help,

Sybrand Bakker
Senior IS Analyst,
Bentley Systems Europe.
Sybrand.bakker_at_bentley.nl

Melinda Schall wrote:

> I am interested in hearing from anyone who has implemented or has knowledge
> of Oracle's nls functionality and its limitations relating to replication.
> Specifically,
> I'm wondering if it's possible to replicate between two databases that are
> built with
> different Character Encoding Schemes (for example: WE8ISO8859P1 -- West
> European and
> JA16SJIS Japanese Shift-JIS).
>
> Even if this proves impossible (which I'm guessing it is) I'm interested in
> hearing about
> any solutions/ ideas regarding the global rollup of
> information from databases with different Character Encoding Schemes.
>
> What I want to figure out is how best to allow users of the database in
> each country
> to input most information in their own language; yet allow the sharing of
> some information
> (with the shared information being in English) between users in other
> countries through the
> use of replication.
>
> Or even if someone could point me somewhere with more information on
> Oracle's NLS
> functionality than the basic Oracle manuals provide. What I need more than
> anything
> is a listing/explanation of the limitations of nls.
>
> Also, I'm working in an Oracle 7.3.2 environment on NCR/UNIX.
> Thanks in advance for any help or discussion.
Received on Thu Nov 13 1997 - 00:00:00 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US