Character set migration error to UTF8 urgent

Hi
when we migrated from ar8iso889p6 to utf8 characterset we are facing one error when i try to compile one package through forms i am getting error program unit pu not found.
When i running the source code of that procedure direct from database using sqlplus its running wihtout any problem.How can i migrate this forms from ar8iso889p6 to utf8 characterset. We migrated from databas with ar8iso889p6 oracle 81.7 database to oracle 9.2. database with character set UTF8 (windows 2000) export and import done without any error
I am using oracle 11i inside the calling forms6i and reports 6i
with regards
ramya
1) this is server side program yaa when connecting with forms i am getting error .When i am running this program using direct sql its working when i running compiling i am getting this error.
3) yes i am using 11 i (11.5.10) inside its calling forms 6i and reports .Why this is giving problem using forms.Is there any setting changing in forms nls_lang
with regards

Hi Ramya
what i understand from your question is that you are trying to compile a procedure from a forms interface at client side?
if yes you should check the code in the forms that is calling the compilation package.
does it contains strings that might be affected from the character set change???
Tony G.

Similar Messages

Clarification on Character set migration from US7ASCII to UTF8

Hi,
I need clarification on the below.
I need to migrate the database from US7ASCII to UTF8.
For this I ran csscan for user "TEST" as well as against full database.
Below log is the csscan output against full database. but my application is depended on TEST schema only. Shall I need to migrate SYS objects data as shown below or it's not required?. If required how to migrate these objects data?
Looking forward you help.
USER.TABLE Convertible Exceptional
SYS.METASTYLESHEET 58 TEST.Table_1 9 0
TEST.Table_2 11 0
TEST.Table_3 17 0
TEST.Table_4 11 0
[Distribution of Convertible Data per Column]
USER.TABLE|COLUMN Convertible Exceptional
SYS.METASTYLESHEET|STYLESHEET 58 0
Thanks,
Sankar

I think you need to migrate all schemas data not only one application schema because
the database character set is common to all CHAR, VARCHAR2, LONG and CLOB colums
for any tables in any schema.
In your case (US7ASCII to UTF8), you need to use export/import because:
Another restriction of the ALTER DATABASE CHARACTER SET statement is that it can be used only when the character set migration is between two single-byte character sets or between two multibyte character sets. If the planned character set migration is from a single-byte character set to a multibyte character set, then use the Export and Import utilities.
(see http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1009904)

Character Set Migration - Arabic & English Language Support

Hi,
Sofware Specifications:
OS Version : Windows 2003 EE Server, SP2, 32-Bit
DB Version : 9.2.0.1
Application : Lotus Domino 6.5
Existing Set Up:
DB CHAR SET : WE8MSWIN 1252
National Character Set : AL16UTF16
NLS_LANG : NA
Now the customer extended their business in EGYPT.
They need the existing database to support ARABIC & ENGLISH Languages.
Kindly let me know how to do this character set migration and achieve the client specification.
Regards
Suresh

Check Metalink
Note:179133.1
Subject:      The correct NLS_LANG in a Windows Environment
Note:187739.1
Subject:      NLS Setup in a Multilingual Database Environment
Note:260023.1
Subject:      Difference between AR8MSWIN1256 and AR8ISO8859P6 characterset
Also, please list all the steps you have performed till now

New white paper: Character Set Migration Best Practices

This paper can be found on the Globalization Home Page at:
http://technet.oracle.com/tech/globalization/pdf/mwp.pdf
This paper outlines the best practices for database character set
migration that has been utilized on behalf of hundreds of customers
successfully. Following these methods will help determine what
strategies are best suited for your environment and will help minimize
risk and downtime. This paper also highlights migration to Unicode.
Many customers today are finding Unicode to be essential to supporting
their global businesses.

Sorry about that. I posted that too soon. It should become available today (Monday Aug 22nd).
Doug

Database character set migration rules

We have an application which migrates various entities from one database to the other. These databases could have different character sets. The migration process is automated. What character set rules should we follow while migration? Can we use the character set scanner is some automated way?
Does ORACLE publish a comprehensive list of subsets and supersets? (and I am NOT talking about strict subsets and supersets) I know that you have a whitepaper which has some rules but that is not a complete set. Any help would be much appreciated. This is an urgent requirement.

There is no simple answer as this is a complex process. You make reference to having looked at a whitepaper on this subject so I assume you know that your application will likely need to dynamically set the nls_lang setting so that proper conversion can take place on the database.
To find what character sets are subsets or supersets of what character sets?
A) The only listing available is in the 8.1.7 Document addendum shipped with the rdbms CD. This document can be found on the web at:
http://technet.oracle.com/docs/products/oracle8i/doc_index.htm
There is no real elegant way to determine possible lossy data situations programmically. Using the scanner to detect within your program whether proper conversion will take place might be possible. There is a documented v$ table that is updated when the scanner is run that could be examined
via SQL in your program to detect lossy data and truncation. You could also possibly use the PL/SQL convert function to detect lossy data. Something like if 'string' = convert('string', us7ascii, WE8MSWIN1252) then ....
Hope this helps.

Character Set conversion 'WE8ISO8859P15' to 'UTF8' in Oracle 11g

Currently we have database with NLS_CHARACTERSET property as WE8ISO8859P15'. we want to change the existing database NLS_CHARACTERSET property to UTF8. How to change NLS_CHARACTERSET from 'WE8ISO8859P15' to 'UTF8' without database loss in the existing schema of oracle11g database.
Please provide the detailed steps to do this process.
Thanks for your assistance on this.

Upgrade to 11.2.0.3, if you do not already run this patch set, and use the Database Migration Assistant for Unicode (DMU): http://www.oracle.com/technetwork/products/globalization/dmu/overview/index.html Read the DMU documentation first: http://docs.oracle.com/cd/E39404_01/welcome.html . This will help you understand the process. If you have questions after reading the documentation, ask them on the DMU forum: Database Migration Assistant for Unicode
By the way, do not migrate to UTF8 unless you use eBS 11i or some other software that needs Oracle Database Client 8.x libraries. Use AL32UTF8 instead.
-- Sergiusz

Unable to migrate table, character set from WE8MSWIN1252 to AL32UTF8

Hi,
On our source db the character set is AL32UTF8
On our own db, we used the default character set of WE8MSWIN1252 .
When migrating one of the table, we get an error of this: ORA-29275: partial multibyte character
So in to alter our character set from WE8MSWIN1252 to AL32UTF8, we get this error:
ALTER DATABASE CHARACTER SET AL32UTF8
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
I would sure not like to reinstall the db and migrate the tables again. Thanks.

See this related thread - Re: Want to change characterset of DB
You can use the ALTER DATABASE CHARACTER SET command in very few cases. You will most likely have to recreate the database and re-migrate the data.
HTH
Srini

Database Character Set Conversion from WE8ISO8859P1 to UTF8

Hi All
I want to migrate data from one database to another database But my original database character set is WE8ISO8859P1 but i want to migrate it to
database which has character set UTF8
because of character set it don't shows me Marathi data which is in original database .
it shows me some symbol for Marathi words ..
please help me out.
Thanking You
Gaurav Sontakke

Dear GauravSontakke,
Since your database version is unknown, i will show you an online documentation of character set migration for 10gR2.
http://www.oracle.com/pls/db102/search?remark=quick_search&word=character+set+migration&tab_id=&format=ranked
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#sthref1442
*http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#NLSPG011*Please read those carefully.
Hope it Helps,
Ogan

Migrating from 8.1.7 to 9.2 with different character set

Are there going to be issues when I try to migrate from 8.1.7 to 9.2 where the character set in the 8i database was the default western european to utf8 in 9i?
I ran the 8i scan utility to see if there would be issues importing into an 8i db with a different char set and it said that there would.

Hi Jim,
As your first step, I would recommend reading the white paper Character Set Migration Best Practices for Oracle9i on the Globalization Support Home page - http://otn.oracle.com/tech/globalization/index.html
Since you mentioned that CSSCAN has already reported there are potential issues (I guess you have exceptional/Lossy data ?), I would strongly recommend splitting up the UTF8 character set change and the database version upgrade into 2 distant phrases. Probably moving to UTF8 in 8.1.7 first, then upgrading to 9.2 later.
BTW, there is a separate Globlization Support and NLS discussion forum on OTN for further discussion on character set related issues.
Nat

ADADMIN Convert Character Set CUSTOM_TOP

Hi All,
I am in the process of converting my 11i instance to UTF8. The database has been converted using DMU. The application folder structure is conveted using the ADADMIN utility.
The conversion of APPL_TOP is fine and no issues.
The conversion of CUSTOM_TOP created issues, the permission of files have chagned and none of the files in the custom top has execute permission.
Has anyone done characteset conversion in the past?
How to handle the CUSTOM_TOP character set conversion ? Can we just ignore the CUSTOM_TOP from converting to UTF8 ?
Regards
Sridhar M

The files that were present in the CUSTOM_TOP during the conversion had their permissions changed after the conversion. ie., none of the files had the execute privilege and hence the users were getting permission denied error on the CUSTOM objects.You can simply set the execute permission on those files.
If you have followed any metalink document please share it with me. Please see the docs referenced in these threads.
Character Set Migration
Oracle E-Biz Applications Database characterset conversion
MLS Data Character Set Conversion
http://forums.oracle.com/forums/search.jspa?threadID=&q=Convert+AND+Characterset&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
http://forums.oracle.com/forums/search.jspa?threadID=&q=Migrate+AND+Characterset&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
Thanks,
Hussein

Change character set

Hi
is anyone can tell me how to change characterset.
i try with alter session but it doesnt work.
thanks

Article from Metalink
Doc ID: Note:66320.1
Subject: Changing the Database Character Set or the Database National Character Set
Type: BULLETIN
Status: PUBLISHED
 Content Type: TEXT/PLAIN
Creation Date: 23-OCT-1998
Last Revision Date: 12-DEC-2003
PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> STARTUP MOUNT; ALTER SYSTEM ENABLE RESTRICTED SESSION; ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; ALTER SYSTEM SET AQ_TM_PROCESSES=0; ALTER DATABASE OPEN; ALTER DATABASE CHARACTER SET <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
 Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Joel P�rez

Character Set conversion fails

Hi,
We have 2 databases, both are UTF8. One database fetches the data from other via a DB Link. Say there are 2 databases A and B. A fetches data from B. A is in WE8ISO8859P1 character set and B is in EEC8EUROPA3 . While fetching the data european characters come as junk in database A. I tried using convert but that too fails.
Can you please suggest if there is any way where i can have the characters presereved?
Thanks.

Hi Deng,
I notice you had a similar problem to james chen, regarding
character set conversion errors and that you did indeed fix
this problem?
Re: DB Link not working
I'd really appreciate it if you could please can you post
onto James' query and let him and other members know your
solution.
Given that members of the Designer community use the forum
to work together and help other members, I think they would
also appreciate this information!
Thanks for your help.
Regards,
Dominic
Designer Prod Mgt
Oracle Corp

How to exp/imp both diff character set tables between in DB1 and DB2?

In the Solaris 2.7 ,the oracle 8i DB1 has NLS_CHARACTERSET
ZHS16CGB231280 and NLS_NCHAR_CHARACTERSET ZHS16CGB231280
character set.
In other linux7.2 system ,the oracle 8i DB2 is install into the
NLS_NCHAR_CHARACTERSET US7ASCII and NLS_CHARACTERSET US7ASCII
character set.
The tables contents of DB1 have some chinese. I want to exp/imp
tables of DB1 into DB2 . But the chinese can't correct display
in the SQLWheet tools. How do the Exp/Imp operation ? ples help
me . thanks .

The supported way to store GB231280-encoded characters is using a ZHS16CGB231280 database or a database created using a superset of GB231280 ,such as UTF8 .Can you not upgrade your target database from US7ASCII to ZHS16CGB231280 ?
With US7ASCII and NLS_LANG set to US7ASCII , you are using the garbage in garbage out (GIGO) approach. This may seem to work but there are many hidden problems :-
1. Invalid SQL String Function behaviours - LENGTH ( ) , SUBSTR ( ) , INSTR ( )
2. Data can be corrupted when data is loaded into another database. e.g. EXP / IMP , Dblinks
3. Communication with other clients will generate incorrect results. e.g. other Oracle products - Oracle Text, Forms. , Java , HTML etc.
4. Linguistic sorts not available
5. Query using the standard WHERE clause may return incorrect results ..
6. Extra coding overhead in handling character conversions manually.
I recommend you to check out the FAQ and the DB Character set migration guide on the Globalization Support forum on OTN.
Nat.

Unable to alter character set from WE8MSWIN1252 to AL32UTF8

Hi,
I am trying to migrate some tables to my database.
On the source DB, the character set is AL32UTF8
On My database, the character set is WE8MSWIN1252.
When I tried to alter the character set, I get this error message:
ALTER DATABASE CHARACTER SET AL32UTF8
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
Any help? Thanks.

Pl refrain from posting duplicate threads :-)
Unable to migrate table, character set from WE8MSWIN1252 to AL32UTF8
Srini

Character set AL32UTF8;

Hello All,
I have oracle 10gr2 and i want to get support of Portuguese character set, for that , i suppose AL32UTF8 is recommended, but when i try to modify the character set i get this error.
SQL> select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
VALUE
WE8ISO8859P1
SQL> alter database character set AL32UTF8;
alter database character set AL32UTF8
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
what should i do now? any idea?
thanks

here it is:
SQL> select news_detail from news_tbl;
NEWS_DETAIL
A Directora nacional-Adjunta do Patrim?nio ligado ao Minist?rio das Finan?as
de Mo?ambique, Albertina Fruquia, esteve nesta quarta-feira, do dia 22 de Novemb
ro, na Secretaria de Log?stica e Tecnologia de Informa??o ( SLTI )para conhecer
o sistema de compras do Governo Federal Brasileiro e verificar a possibilidade d
e estabelecer acordos de coopera??o nessa ?rea.
 
Na opini?o da Directora Mo?ambicana, o Brasil tem uma experi?ncia importante
em compras p?blicas que pode colaborar com Mo?ambique nesta ?rea. Ela lembrou qu
e o pa?s Africano est? imlpementando um novo regulamento de compras que constitu
i o preg?o presencial, modalidade regulamentada no Brasil desde 2000.
 
you can see that even in sqlplus the data is not shown the portugueses language chars, now what you think, that whether this data is stored wrong or either i can recover it by changing chars set or language?
Message was edited by:
nayyares
Message was edited by:
nayyares

Character set migration error to UTF8 urgent

Similar Messages

Maybe you are looking for