Re: NLS_LANG charecters set .. and more.

Marco BANO wrote in message <3715F7EA.ACC2C821_at_eumetsat.de>...
>hi,
>
>Why I need to create my database with WE8ISO8859... when I could store
>any 8 bits characters even in a US7ascii database ?.
>I don't understand the logic of .. characters. export/import... etc etc.
>

You don't have to create it with WE8ISO8859..., you can create it with any of the character sets that Oracle recognises (look at National Language Support in "Server Concepts" in your documentation set). Of course, you will have to choose a character set that defines all the national language characters that you're using!

The reason you have to specify a character set for the database is that this enables Oracle clients with different character sets than the database's to display and store national language characters.

An example:

- You have a WEISO8859P1 as database character set
- Some of your Oracle clients use WEISO8859P1
- Some of your Oracle clients use WE8EBCDIC37

When one of your WE8EBCDIC37 clients inserts into, or retrieves from the database a national language character, Oracle automatically translates between the two character sets. If the database was not told which character set it was storing, this would not have been possible, without you handling it yourself, writing separate applications for the different clients' character sets.

IMPORTANT! Your Oracle client must be configured for a character set, namely the character set of your client platform! For this, the NLS_LANG environment variable/registry value is used. On Windows 95/98/NT, this is handled for you by the Oracle installer. On other clients, you may have to define it yourself. If there is a mismatch between the Oracle client's character set and the platform's character set, then Oracle will make false assumptions about the translation, corrupting both database updates and data retrieval (including export - export stores the character set part of the client's NLS_LANG in the export file).

If a translation does not exist (because the character being translated does not exist in the target character set), Oracle translates to a '?'. Misconfiguration of your Oracle client's character set will most likely cause Oracle to think that a lot of translations do not exist, hence translating your national language characters to '?'.

So, if your export went wrong due to an incorrect NLS_LANG on the client, you have lost, because the national language characters were most likely translated to '?' in the export, and hence will be imported as '?'.

Also, note that the server may be it's own Oracle client, for example when running export/import/sql*plus on the server. Therefore, you *must* configure the correct value for NLS_LANG (for each of the Oracle users' accounts) on your server, too!

Just make sure that the NLS_LANG on your client corresponds to the client's operating system character set, and than NLS_LANG (for each of the oracle users' accounts) on your server corresponds to the server's operating system character set, and you're on safe ground. The Oracle client does not (and should not) know the database's character set - this is handled by the Oracle server.

Just to add to the confusion, it is perfectly all right to create the database with a different character set than the one your server's operating system uses! In the above example, it would make sense to create the database with WE8EBCDIC37 if most of your clients use WE8EBCDIC37, because translation degrades performance somewhat.

>THANK you for any ... answer.
>
>I am newby.. here so I hope help you in the future.
>

Good thinking!

>
>
>
>--
>Marco BANO
>Network administrator Consultant
>EUMETSAT
>Am Kavalleriesand 31
>64295 DARMSTADT
>Germany
>
>Office : ++49 6151 807536
>
>

Regards,

Roy Brokvam
roy.brokvam_at_conax.com Received on Thu Apr 15 1999 - 11:42:44 CDT