Character Set not supported

Hi,
I use Repository Administrative to create a new repository, but i got a error: "process aborted"
Then i checked the log file, which is Character Set not support from type 31 to type 852
anybody knows any solution about that
Thanks in advance

Just ran into this myself yester day.
There is a Metalink Note on it.
http://metalink.oracle.com/metalink/plsql/ml2_documents.showFrameDocument?p_database_id=NOT&p_id=190281.1
Problem Description
You are using OC4J and trying to connect to a database using JDBC OCI and
are getting:
"java.sql.SQLException: Character Set Not Supported !!: DBConversion"
Solution Description
Replace the <OC4J_HOME>\jdbc\lib\classes12dms.jar with
<ORACLE_HOME>\jdbc\lib\classes12.jar and rename it with classes12dms.jar.
Explanation
It seems there is a mismatch of classes12.zip supplied with OC4J 9.0.2
and the Oracle9i client libraries ocijdbc8.dll or ocijdbc8.so.
OC4J 9.0.2 does not use jdbc\lib\classes12.jar instead it uses
jdbc\lib\classes12dms.jar. So, in order to use the 9.0.1 client with OC4J, you
will need to make a copy of classes12.jar and rename it to classes12dms.jar
References
[NOTE:108876.1] Creating Connection gives "No ocijdbc8 in java.library.path"
[NOTE:174808.1] JDev9i and OCI Connections
I copied and renamed the jar (classes12.jar) as they stated.
Note: It should be in the directory you set in the JDev.conf, mine is
AddNativeCodePath D:\OraNT\9iDS\bin
Didn't try the other reply's suggestion of setting an environment variable.

Similar Messages

SQLException Character Set Not Supported

I'm at wit's end.
I have the following versions:
Win2k
JDeveloper 9i R2
Oracle9iAS 9.0.3.0.0
Oracle 9i client 9.0.1.1
Sun J2SDK 1.3.1
Oracle 9i Enterprize Edition 9.0.1.3.0
I'm trying to get a JDBC connection from a DataSource in a servlet. The result is the following error: java.sql.SQLException: Character Set Not Supported !!: DBConversion.
I get the same problem just trying a simple JDBC connection in JDeveloper. I can fix this problem by forcing JDeveloper to use classes12.jar from the Oracle client directory BEFORE oc4j.jar in the JDeveloper libraries.
Unfortunately, I can't get the external 9iAS server to make this switch. It's (naturally) using its copy of oc4j.jar.
Any ideas on:
1) How to properly avoid the Character Set error.
2) How to force 9i AS to use different libraries before it looks in oc4j.
Any help is greatly appreciated

I have tried the embedded server in JDeveloper with the same results. Currently, I am using the external one.
I believe the data source is valid. I can duplicate this problem by just using a plain JDBC connection from DriverManager. Also, I switched to the 1.0.2 version of oc4j, replaced the Oracle stuff with 8i versions and was able to connect using the same data-sources.xml.
This problem also goes away when using the thin driver but we're reluctant to use the thin driver for performance reasons.
Thanks for the response,
TG

Character set not supported!! DBConversion error. Need Help!

I installed JDeveloper9.2 on windows 2000. When I try to make a database server connection by using OCI8 driver, it gives me a "Character set not supported DBConversion error". After that I tried to connect database by using Thin driver, everything is OK. I really need your help.
I used database connection wizard to make the connection. Connection type I selected ORACLE(JDBC) and drive I selected OCI8. After that I tried to test connection, it gave me above error. I noticed that JDeveloper did not talked with database server at all, I tried to connect with a database server which does not exist, it still gave me the same error.

Just ran into this myself yester day.
There is a Metalink Note on it.
http://metalink.oracle.com/metalink/plsql/ml2_documents.showFrameDocument?p_database_id=NOT&p_id=190281.1
Problem Description
You are using OC4J and trying to connect to a database using JDBC OCI and
are getting:
"java.sql.SQLException: Character Set Not Supported !!: DBConversion"
Solution Description
Replace the <OC4J_HOME>\jdbc\lib\classes12dms.jar with
<ORACLE_HOME>\jdbc\lib\classes12.jar and rename it with classes12dms.jar.
Explanation
It seems there is a mismatch of classes12.zip supplied with OC4J 9.0.2
and the Oracle9i client libraries ocijdbc8.dll or ocijdbc8.so.
OC4J 9.0.2 does not use jdbc\lib\classes12.jar instead it uses
jdbc\lib\classes12dms.jar. So, in order to use the 9.0.1 client with OC4J, you
will need to make a copy of classes12.jar and rename it to classes12dms.jar
References
[NOTE:108876.1] Creating Connection gives "No ocijdbc8 in java.library.path"
[NOTE:174808.1] JDev9i and OCI Connections
I copied and renamed the jar (classes12.jar) as they stated.
Note: It should be in the directory you set in the JDev.conf, mine is
AddNativeCodePath D:\OraNT\9iDS\bin
Didn't try the other reply's suggestion of setting an environment variable.

Connection oci : Character Set Not Supported !!: DBConversion

I4m working with Oracle client 9.0.1.1.1 and JDeveloper 9.0.2.7.86 (Release Candidate 2). I have an application that connects a DB using OCI. The application is all right, but if I do the same from a JSP, it don4t get the connection and return the following error: '!!Juego de caracteres no soportado!!: DBConversion'
If I execute the same code in a PC with the Oracle client 8.1.7.0.0 and JDeveloper 5.0.581 (Beta Release), everything is well... (OCI8)
Thanks in advance

I4m working with Oracle client 9.0.1.1.1 and JDeveloper 9.0.2.7.86 (Release Candidate 2). I have an application that connects a DB using OCI. The application is all right, but if I do the same from a JSP, it don4t get the connection and return the following error: '!!Juego de caracteres no soportado!!: DBConversion'
If I execute the same code in a PC with the Oracle client 8.1.7.0.0 and JDeveloper 5.0.581 (Beta Release), everything is well... (OCI8)
Thanks in advance The JDBC-OCI driver included with JDeveloper is 9.0.2, and requires the 9.0.2 database client (which is available on the 1 IAS Administrative client CD, or the 2 IDS CD's. A mis-match between the JNI code is causing this error. Install the Oracle Client from the IAS Administrative CD for Windows.
Hope this helps,
Rob

Failed to load Sorce Model: Encoding or code set not supported

Hello,
I have tried to migrate an informix-db with error "Failed to load Sorce Model: Encoding or code set not supported".
Informix: 7.3.1
Unix: Reliant-Unix 5.45
Repository: Oracle 8.1.7 (64bit) EE [tested with the same output 8.1.6]
Unix: Reliant-Unix 5.44
error.log:
** Oracle Migration Workbench
** Release 2.0.2.0.0 Production
** ( Build 20011121 )
** ORACLE_HOME: D:\wntapp\omwb
** user language: de
** user region: DE
** user timezone: ECT
** file encoding: Cp1252
** java version: 1.1.8.10
** java vendor: Oracle Corporation
** o.s. arch: x86
** o.s. name: Windows NT
** o.s. version: 4.0
** Classpath:
D:\wntapp\omwb\Omwb\olite\Oljdk11.jar;D:\wntapp\omwb\Omwb\olite\Olite40.jar;C:\Programme\Oracle\jre\1.1.8\lib\rt.jar;C:\Programme\Oracle\jre\1.1.8\lib\i18n.jar;D:\wntapp\omwb\Omwb\jlib;D:\wntapp\omwb\Omwb\jlib\Omwb.jar;D:\wntapp\omwb\jlib\oembase-9_0_1.jar;D:\wntapp\omwb\jlib\netcfg.jar;D:\wntapp\omwb\Omwb\plugins\SQLServer6.jar;D:\wntapp\omwb\Omwb\plugins\SQLServer7.jar;D:\wntapp\omwb\Omwb\plugins\SQLServer2K.jar;D:\wntapp\omwb\Omwb\plugins\Sybase11.jar;D:\wntapp\omwb\Omwb\plugins\Sybase12.jar;D:\wntapp\omwb\Omwb\plugins\MSAccess.jar;D:\wntapp\omwb\Omwb\plugins\MySQL.jar;D:\wntapp\omwb\Omwb\drivers\mm.mysql.jdbc-1.2a;D:\wntapp\omwb\Omwb\plugins\Informix7.jar;D:\wntapp\omwb\Omwb\drivers\ifxjdbc.jar;D:\wntapp\omwb\lib\xmlparserv2.jar;D:\wntapp\omwb\rdbms\jlib\xsu111.jar;D:\wntapp\omwb\jdbc\lib\classes111.zip;D:\wntapp\omwb\lib\vbjorb.jar;D:\wntapp\omwb\jlib\ewt-swingaccess-3_3_18.jar;D:\wntapp\omwb\jlib\ewt-3_3_18.jar;D:\wntapp\omwb\jlib\ewtcompat-3_3_15.jar;D:\wntapp\omwb\jlib\share-1_1_9.jar;D:\wntapp\omwb\j
lib\help-3_2_9.jar;D:\wntapp\omwb\jlib\ice-5_06_3.jar;D:\wntapp\omwb\jlib\kodiak-1_2_1.jar
** Started : Mon Feb 18 13:39:24 CET 2002
** The following plugins are installed:
** Informix Dynamic Server 7.3 Release 2.0.2.0.0 Production
EXCEPTION : LoadTableData.run() : IDS7_SYSCOLUMNS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSTABLES Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSUSERS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSBLOBS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSVIEWS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSCOLDEPEND Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSREFERENCES Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSOBJSTATE Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSTRIGGERS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSTRIGBODY Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSSYNONYMS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSSYNTABLE Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSDEFAULTS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSCONSTRAINTS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSCHECKS Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSPROCEDURES Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSINDEXES Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSTABAUTH Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSROLEAUTH Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSPROCAUTH Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSCOLAUTH Encoding or code set not supported.
EXCEPTION : LoadTableData.run() : IDS7_SYSPROCBODY Encoding or code set not supported.
Please help.
Thanks
G. Grosche

Looks like this error is comming from the Informix JDBC Driver.
what version of the JDBC Driver are you using and is there anything special
about the character set you used to create your database?
Can you build a simple Java app to connect to the same database with the same JDBC Driver?
Jim.

Character set supported by post and util.zip

hi friends
in my application i was sending a file(in client) using post method and in server getting using servlets.i what that file to be compressed using util.zip in client and uncompresed in server but i was unsucessful .i think the file before post (compressed one) and retrieving one are not same. is it problem different character set supported by http and zip files? or any thing else?
plz help me.......

Just ran into this myself yester day.
There is a Metalink Note on it.
http://metalink.oracle.com/metalink/plsql/ml2_documents.showFrameDocument?p_database_id=NOT&p_id=190281.1
Problem Description
You are using OC4J and trying to connect to a database using JDBC OCI and
are getting:
"java.sql.SQLException: Character Set Not Supported !!: DBConversion"
Solution Description
Replace the <OC4J_HOME>\jdbc\lib\classes12dms.jar with
<ORACLE_HOME>\jdbc\lib\classes12.jar and rename it with classes12dms.jar.
Explanation
It seems there is a mismatch of classes12.zip supplied with OC4J 9.0.2
and the Oracle9i client libraries ocijdbc8.dll or ocijdbc8.so.
OC4J 9.0.2 does not use jdbc\lib\classes12.jar instead it uses
jdbc\lib\classes12dms.jar. So, in order to use the 9.0.1 client with OC4J, you
will need to make a copy of classes12.jar and rename it to classes12dms.jar
References
[NOTE:108876.1] Creating Connection gives "No ocijdbc8 in java.library.path"
[NOTE:174808.1] JDev9i and OCI Connections
I copied and renamed the jar (classes12.jar) as they stated.
Note: It should be in the directory you set in the JDev.conf, mine is
AddNativeCodePath D:\OraNT\9iDS\bin
Didn't try the other reply's suggestion of setting an environment variable.

Customising character sets

We are trying to migrate to an oracle 8.1.7 database with UTF8 as database character set. A lot of the clients (windows) will still be using a company-specific character set, so there was an need to define/compile/install this character set in the NLS directory of oracle using .nlt files and the lxinst utility.
While was trying to do this, a some questions emerged that where not addressed in the oracle documentation for NLS and Globalisation.
The custom character set is based on the US-ASCII character set, so I thought to use
base_char_set = US7ASCII
and define the other characters starting from 0x80 and ending with 0xff
-     but when I tried to compile this charset on AIX (server side) it gave a lot of warnings:
LXI-WARN-00510: In lx22712.nlt at line 88, unicode 0x300 out of private use range
LXI-WARN-00512: In lx22712.nlt at line 88, character 0x80 is remapped
LXI-WARN-00510: In lx22712.nlt at line 89, unicode 0x302 out of private use range
LXI-WARN-00512: In lx22712.nlt at line 89, character 0x81 is remapped
-     when I tried to compile this on windows 2000 (client side) lxinst generates an application error
Because this base_char_set definition did not work (or I made a mistake), I left it out of the definition file, and I mapped the characters using:
character_data = {
0x00 - 0x7f : 0x0000 - 0x007f,
this compiles fine on both platforms. But this means that I have to fill in the classification list, the upper-to-lower and lower-to-upper relationships for all these characters, so it would be a lot easier if this base_char_set worked.
other questions:
-     About the character classification list:
can such a list contain more than 2 classifications? For example
0xC0 = {LETTER, UPPER, PRINTABLE}
what are exactly the differences between those classifications? (for example can a character be a LETTER but not PRINTABLE)
-     What about combining characters: in most character sets (also in ours) a combining character precedes the character it will be combined with, in a string. In Unicode the combining character comes after the character it will be combined with. When oracle converts strings between two such charsets, will the combining characters be handled according to the character set it is converting to, or will the order of characters in the string stay the same?
--Janick

Thanks for the help,
the reason for needing a customised character set is not because of a special input device. Our current client uses this character set (not a standard) to support scripts for different languages. Since we want future clients to use the unicode standard, and want to support more scripts in the future, we are migrating our DB to UTF8, but our old clients should still be able to connect and query the DB (for now).
I cannot find this developers version of the OLB. In
Oracle Technology Network > Software >
there is no entry in the drop down boxes for this (or am I looking in the wrong place?)
thank you a lot for the help,
regards,
--Janick

Database character set

Hi brother,
I would like to create new DB which support Simplified Chinese and Traditional Chinese. which character should I choose?
Thanks

If you for some reason don't want to use Unicode ie. AL32UTF8, then for database character set (not national character set), see the Recommended list, table A-4:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/applocaledata.htm#i635016
If you also include "other" character sets, there are several, beginning with ZH that seem to support Chinese language.

Change existing character set

Hi All,
I want to change current character set of my DB.
My DB version is 8.1.7 and character set is US7ASCII.
This character set does not support to store Euro symbol (â¬). So I want to change to another charset.
Currently I also have another DB, version 9.2.0 and charset is AL32UTF8 and National charset is AL16UTF16. This charset supports â¬ symbol.
But when I tried change chatset of 8i US7ASCII to AL32UTF8, an error happened: "ORA-12712 new character set must be a supersetof old character set".
Character set WE8ISO8859P1 support â¬ symbol.
I tried to change character set of 8i from US7ASCII to WE8ISO8859P1 successfully but change character set of 9i from AL32UTF8 to WE8ISO8859P1 unsuccessfully, error is "ORA-12712 new character set must be a supersetof old character set".
Please let me know which character set is superset of US7ASCII and AL32UTF8.
I want to change character set of 8i and 9i to the same another character set that support â¬ symbol.
Thanks in advanced,
Thi Nguyen

This is from Oracle metalink documentation.Hope this helps:
=========================================
This note defines character set combinations which are valid for the 'ALTER DATABASE CHARACTER SET xxxx;' command. A superset, in this context, is a character set where every character in the subset character set is defined and is defined at the same code point. Changing the Database Character Set or the Database National Character Set . If the change you want to do (change from <current> -> <new> characterset) is not listed here, then you need to use Export/Import. Export/Import and NLS Considerations for more info. SCOPE & APPLICATION ------------------- This note is relevant to anyone wishing to change the database character set or the database national character set. Note : this note is relevant from 8.1.6 to 9.2.0. Changing Database Character set - valid superset definitions ------------------------------------------------------------ Where the current character set does not have a corresponding match in the new character set column, it is not possible to change the definition by the above command alone; export / import into a new database with the new character set (not in the following list) will be required. 8.1.6 Subset/Superset Pairs =========================== A. Current Char set B. New Char set (Superset of A.) ------------------- -------------------------------- US7ASCII WE8DEC US7ASCII US8PC437 US7ASCII WE8PC850 US7ASCII IN8ISCII US7ASCII WE8PC858 US7ASCII WE8ISO8859P1 US7ASCII EE8ISO8859P2 US7ASCII SE8ISO8859P3 US7ASCII NEE8ISO8859P4 US7ASCII CL8ISO8859P5 US7ASCII AR8ISO8859P6 US7ASCII EL8ISO8859P7 US7ASCII IW8ISO8859P8 US7ASCII WE8ISO8859P9 US7ASCII NE8ISO8859P10 US7ASCII TH8TISASCII US7ASCII BN8BSCII US7ASCII VN8VN3 US7ASCII VN8MSWIN1258 US7ASCII WE8ISO8859P15 US7ASCII WE8NEXTSTEP US7ASCII AR8ASMO708PLUS US7ASCII EL8DEC US7ASCII TR8DEC US7ASCII LA8PASSPORT US7ASCII BG8PC437S US7ASCII EE8PC852 US7ASCII RU8PC866 US7ASCII RU8BESTA US7ASCII IW8PC1507 US7ASCII RU8PC855 US7ASCII TR8PC857 US7ASCII CL8MACCYRILLICS US7ASCII WE8PC860 US7ASCII IS8PC861 US7ASCII EE8MACCES US7ASCII EE8MACCROATIANS US7ASCII TR8MACTURKISHS US7ASCII EL8MACGREEKS US7ASCII IW8MACHEBREWS US7ASCII EE8MSWIN1250 US7ASCII CL8MSWIN1251 US7ASCII ET8MSWIN923 US7ASCII BG8MSWIN US7ASCII EL8MSWIN1253 US7ASCII IW8MSWIN1255 US7ASCII LT8MSWIN921 US7ASCII TR8MSWIN1254 US7ASCII WE8MSWIN1252 US7ASCII BLT8MSWIN1257 US7ASCII N8PC865 US7ASCII BLT8CP921 US7ASCII LV8PC1117 US7ASCII LV8PC8LR US7ASCII LV8RST104090 US7ASCII CL8KOI8R US7ASCII BLT8PC775 US7ASCII WE8DG US7ASCII WE8NCR4970 US7ASCII WE8ROMAN8 US7ASCII WE8MACROMAN8S US7ASCII TH8MACTHAIS US7ASCII HU8CWI2 US7ASCII EL8PC437S US7ASCII LT8PC772 US7ASCII LT8PC774 US7ASCII EL8PC869 US7ASCII EL8PC851 US7ASCII CDN8PC863 US7ASCII HU8ABMOD US7ASCII AR8ASMO8X US7ASCII AR8NAFITHA711T US7ASCII AR8SAKHR707T US7ASCII AR8MUSSAD768T US7ASCII AR8ADOS710T US7ASCII AR8ADOS720T US7ASCII AR8APTEC715T US7ASCII AR8NAFITHA721T US7ASCII AR8HPARABIC8T US7ASCII AR8NAFITHA711 US7ASCII AR8SAKHR707 US7ASCII AR8MUSSAD768 US7ASCII AR8ADOS710 US7ASCII AR8ADOS720 US7ASCII AR8APTEC715 US7ASCII AR8MSAWIN US7ASCII AR8NAFITHA721 US7ASCII AR8SAKHR706 US7ASCII AR8ARABICMACS US7ASCII LA8ISO6937 US7ASCII JA16VMS US7ASCII JA16EUC US7ASCII JA16SJIS US7ASCII KO16KSC5601 US7ASCII KO16KSCCS US7ASCII KO16MSWIN949 US7ASCII ZHS16CGB231280 US7ASCII ZHS16GBK US7ASCII ZHT32EUC US7ASCII ZHT32SOPS US7ASCII ZHT16DBT US7ASCII ZHT32TRIS US7ASCII ZHT16BIG5 US7ASCII ZHT16CCDC US7ASCII ZHT16MSWIN950 US7ASCII AL24UTFFSS US7ASCII UTF8 US7ASCII JA16TSTSET2 US7ASCII JA16TSTSET 8.1.7 Additions =============== US7ASCII ZHT16HKSCS US7ASCII KO16TSTSET WE8DEC TR8DEC WE8DEC WE8NCR4970 WE8PC850 WE8PC858 D7DEC D7SIEMENS9780X I7DEC I7SIEMENS9780X WE8ISO8859P1 WE8MSWIN1252 AR8ISO8859P6 AR8ASMO708PLUS AR8ISO8859P6 AR8ASMO8X IW8EBCDIC424 IW8EBCDIC1086 IW8EBCDIC1086 IW8EBCDIC424 LV8PC8LR LV8RST104090 DK7SIEMENS9780X N7SIEMENS9780X N7SIEMENS9780X DK7SIEMENS9780X I7SIEMENS9780X I7DEC D7SIEMENS9780X D7DEC WE8NCR4970 WE8DEC WE8NCR4970 TR8DEC AR8SAKHR707T AR8SAKHR707 AR8MUSSAD768T AR8MUSSAD768 AR8ADOS720T AR8ADOS720 AR8NAFITHA711 AR8NAFITHA711T AR8SAKHR707 AR8SAKHR707T AR8MUSSAD768 AR8MUSSAD768T AR8ADOS710 AR8ADOS710T AR8ADOS720 AR8ADOS720T AR8APTEC715 AR8APTEC715T AR8NAFITHA721 AR8NAFITHA721T AR8ARABICMAC AR8ARABICMACT AR8ARABICMACT AR8ARABICMAC KO16KSC5601 KO16MSWIN949 WE16DECTST2 WE16DECTST WE16DECTST WE16DECTST2 9.0.1 Additions =============== US7ASCII BLT8ISO8859P13 US7ASCII CEL8ISO8859P14 US7ASCII CL8ISOIR111 US7ASCII CL8KOI8U US7ASCII AL32UTF8 BLT8CP921 BLT8ISO8859P13 US7ASCII AR8MSWIN1256 UTF8 AL32UTF8 (added in patchset 9.0.1.2) Character Set Subset/Superset Pairs Obsolete from 9.0.1 ======================================================= US7ASCII AR8MSAWIN AR8ARABICMAC AR8ARABICMACT 9.2.0 Additions =============== US7ASCII JA16EUCTILDE US7ASCII JA16SJISTILDE US7ASCII ZHS32GB18030 US7ASCII ZHT32EUCTST WE8ISO8859P9 TR8MSWIN1254 LT8MSWIN921 BLT8ISO8859P13 LT8MSWIN921 BLT8CP921 BLT8CP921 LT8MSWIN921 AR8ARABICMAC AR8ARABICMACT ZHT32EUC ZHT32EUCTST UTF8 AL32UTF8 Character Set Subset/Superset Pairs Obsolete from 9.2.0 ======================================================= LV8PC8LR LV8RST104090

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

Oracle 8.1.5 install on Linux Redhat 6.0: character set (and other) problem(s)

I am trying to install Oracle 8i on Linux and it does not work : once the install is finished, I have a message saying that "Character Set not found".
I am runing a french version of Linux (fr-latin 1) and I try to install Oracle with French and English as languages
An other problem about this install : Oracle does not seem to recognize that I have 6,9 Giga for it to install, and says that I have not enough space for the install...
And at the end of the install, it takes for ages (about 15mns) during which nothing seems to happen. On one machine I got out of this phase, but on the other I never saw it finish, it looks as if the computer crashed. Is that normal?
I went through all the initialization phases, set the correct environment variables...
thanks
Solange
null

I've been dealing with the same problems in the english version but could bypass thiss by doing the folowing.
-Just ignore the disk space stuff
-Ignore the charset message, also
-When creating a database, choose custom and then select the WE8ISO8859P1 char set. It worked for portuguese, must work for french also.
-Everyone here recommended, and I do the same, leave the database creation for later, not during instalation.
Good Luck!

Function to change character set for specific text

Hi all,
there is any function that i can use to change specific character from AL16UTF16 character set to UTF8 character set,
there is any such a function in oracle doing this ..
Thanks in advance
Ahmed,

HI Elic,
The things is my CharacterSet is AR8MSWIN1256
and i want to convert it to unicode character set that supported arabic
can you please tell me ,
ahmed

XML as target file - how can i change its character set?

Hi all,
i need to create my target as XML-file und to save all my information there, but with other character set (not with default). In other words i must have in XML-file in header
<?xml version="1.0" encoding="ISO-8859-15"?>.
Now i have
<?xml version="1.0"?>.
What can i do?
Thanks in advance.

I don't think Finder does this (I've tried).
iTunes does though. Where you can set artwork or the "poster frame"...
This may not be what you want but if it helps, I know 2 ways do this is
Open the video in QuicktimePlayer7 | View | Set Poster Frame (even then, you might need to save it as .mov (ie in a 'mov container').
Drag the file into iTunes and set the artwork (as in http://www.dummies.com/how-to/content/adding-album-cover-art-or-images-in-itunes .html)
From there, iTunes will use that frame as the "poster frame" ie the photo/frame that shows when you browse your videos. Which is what you want, but limited to iTunes.
When I do either of these above, the frame I set does not show when exploring files in "Finder" (or in the other Explorer tool I use called "Pathfinder").
So it maybe, that exactly what you want, is not possible.

Regarding Character set

Hello,
How can I enable the arabic character set to my Oracle XE
SQL> SELECT USERENV ('language') FROM DUAL;
USERENV('LANGUAGE')
AMERICAN_AMERICA.AL32UTF8Thanks & best regards

If this is the "Universal" variant of XE server, then the Database Character set already supports most possible language scripts or alphabets, including arabic. AL32UTF8 is Oracle's implementation of Unicode support. (The site says the standard "...provides the basis for processing, storage and interchange of text data in any language")
XE for Windows [downloads page|http://www.oracle.com/technology/software/products/database/xe/htdocs/102xewinsoft.html] states that: "Multi-byte Unicode database for all language deployment, ...".
Or are you perhaps referring to the APEX user interface? (Don't know if the Apex dev tool/envrionment UI is available in Arabic.)

C2-03 not support streaming and all network settin...

I have C2-03. This set not support all type of network settings and streaming.
Solved!
Go to Solution.

Hi Subhams302,
have you checked with your network carrier that you have the correct settings for Internet and streaming? They may be able to send the settings to you via SMS if they are not correct on the SIM already provided to you.

Character Set not supported

Similar Messages

Maybe you are looking for