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

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Help on Effect of changing NLS_LANGUAGE to maerican_america.u

RE: Help on Effect of changing NLS_LANGUAGE to maerican_america.u

From: Ron Thomas <rthomas_at_hypercom.com>
Date: Wed, 25 Sep 2002 15:23:21 -0800
Message-ID: <F001.004D96E0.20020925152321@fatcity.com>

Since WE8ISO8859P1 is not a strict subset of UTF8, you will need to recreate the database. Since you need to recreate, take to opportunity to upgrade to 8.1.7.4 or 9.0.2

Also, I would suggest upgrading to at least Dev 6i, patchset 6 (6.0.8.15), but preferable patchset 10 (6.0.8.19). This resolved a lot of UTF8 issues we had.

Also, see note below from metalink.

Also realize that your services (forms, reports, listener,etc) sould also run in a UTF8 environment. It will be up to the client to translate to the required regional encoding.

Also realize that printing will now become an issue. Most printers can not handle UTF8 encoded data. You will need to investigate the PASTA print utility, or optionally, run a separate report server for each regional environment.

Also realise...

As you can see, this is not a decision to be made lightly. I'm still struggling with some of these issues. I support an Oracle Applications installation that is multi-national (US, Brazilian Portuguese, and Simplified Chinese)- it's been loads of fun!


                                                                                                                       
                                                                                                                       
                                                                 ## We know that WE8ISO8859P1 is not a strict subset   
                                                                 of UTF8,                                              
                                                                 ## so is a DB receation required to use the new Char  
                                                                 Set?                                                  
                                                                                                                       
                                                                 Yes, it is.                                           
                                                                                                                       
                                                                 ## What are the implications of this conversion?      
                                                                                                                       
                                                                 All strings that are not pure ASCII (codes 0-127)     
                                                                 will expand because the non-ASCII WE8ISO8859P1        
                                                                 characters will occupy 2 bytes each. This must be     
                                                                 accounted for in the new table definitions.           
                                                                                                                       
                                                                 ## Please outline the steps in performing this        
                                                                 conversion.                                           
                                                                                                                       
                                                                 General steps are:                                    
                                                                                                                       

- Use the Character Set Scanner (see otn.oracle.com)
to verify that all your WE8ISO8859P1 data in the old database are Convertible (no Exceptions). Illegal WE8MSWIN1252 characters (like the TM sign, smart quotes, etc.) may appear in WE8ISO885P1 databases used with Windows clients
- Create a new UTF8 database
- If you have scripts to create your application
tables, correct the scripts to make table columns long enough and create the new schemas
- If you do not have the scripts, export the old
database with ROWS=N, import it and use ALTER TABLE to make the necessary length changes
- Export the old database with ROWS=Y; make sure to
set NLS_LANG to .WE8ISO8859P1 before the export
- Import the old database data with IGNORE=Y; make
sure the NLS_LANG is still .WE8ISO8859P1 This basic steps may need refinement due to possible non-NLS related issues with full export/import but this would be out of scope of my answer. ## What should be the NLS_LANG , NLS_CHARACTERSET parameters? NLS_CHARACTERSET is the database character set, i.e. it would be UTF8. NLS_LANG would depend on the way you implement multiple language support in your application. See http://otn.oracle.com/tech/globalization/content.html for some interesting white papers.

Ron Thomas
Hypercom, Inc
rthomas_at_hypercom.com
Each new user of a new system uncovers a new class of bugs. -- Kernighan

                                                                                                                  
                      root_at_fatcity.com                                                                            
                                               To:       ORACLE-L_at_fatcity.com                                     
                      09/25/02 01:13 PM        cc:                                                                
                      Please respond to        Subject:  RE: Help on Effect of changing NLS_LANGUAGE to           
                      ORACLE-L                  maerican_america.u                                                
                                                                                                                  
                                                                                                                  




Sorry Gurus

The database version is: 8.1.6.0.0
Reports: 6.0.5.28.0
Forms: 6.0.5.2

Current NLS_LANGUAGE: AMERICAN
Current NLS_NCHAR_CHARACTERSET: WE8ISO8859P1
Current NLS_CHARACTERSET: WE8ISO8859P1
Current NLS_CALENDAR: GREGORIAN

Appreciate your response

Shiva

-----Original Message-----
Sent: Wednesday, September 25, 2002 1:38 PM To: Multiple recipients of list ORACLE-L maerican_america.utf8

What version of the database? What version of forms/reports? What platform? What is the current
characterset of the database?

Ron Thomas
Hypercom, Inc
rthomas_at_hypercom.com
Each new user of a new system uncovers a new class of bugs. -- Kernighan

7

                      root_at_fatcity.com

                                               To:
ORACLE-L_at_fatcity.com
                      09/25/02 10:03 AM        cc:

                      Please respond to        Subject:  Help on Effect of
changing NLS_LANGUAGE to
                      ORACLE-L                  maerican_america.utf8









Hi Gurus

We customize pharmaceutical processing industry applications. One of our client is going global. The
client needs to change NLS_LANGUAGE setting to NLS_LANG="american_america.utf8".
I would like to know how to change this and

what impacts will it have on reports and forms already custom developed for this client?

There are some barcode checksum calculation procedures for some reports. Will they get impacted by
changing the NLS_LANG?

A input on this is highly appreciated

Regards

Shiva Baswannappa

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Ron Thomas
  INET: rthomas_at_hypercom.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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Baswannappa, Shiva
  INET: SXBaswan_at_dcss.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).




-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Ron Thomas
  INET: rthomas_at_hypercom.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).
Received on Wed Sep 25 2002 - 18:23:21 CDT

Original text of this message

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