Conversion of character sets (UCS2 of MSSQL to AL32UTF8 of Oracle Warehouse

Hi all,
I installed my enviroment as below.
Server:
Windows 7 Professional
SQL Server 20012
Character Set: UCS2
Client:
Linux REDHAT 5
Oracle Warehouse 11gR2 (11.2.0.1)
Oracle Database Gateway for MSSQL Server 11.2.0.1
Character Set:AL32UTF8
I installed the gateway for connecting the Oracle Warehouse with MSSQL DB. However, the characters are not readable, because the character of MSSQL DB is coded via one byte character, and the Oracle character is coded like multibyte character.
Input:
Table name on the MSSQL DB: Table_Name
Output:
Table name on the Oracle Warehouse Import Wirzard:◊T◊a◊b◊le◊_◊N◊a◊m◊e
It causes error by importing the table, because the OWB doesn't allow the unreadable characters of table name.
Do you have an idea for resolving it.
Thanks and kind regards,
Hip

Ok, I have changed it as you wrote:
HS_FDS_CONNECT_INFO=100.30.4.157:1433//bob
HS_FDS_TRACE_LEVEL=255
HS_FDS_RECOVERY_ACCOUNT=RECOVER
HS_FDS_RECOVERY_PWD=RECOVER
HS_TRANSACTION_MODEL=READ_ONLY
HS_LANGUAGE=american_america.we8mswin1252
HS_NLS_NCHAR=UCS2
HS_NLS_LENGTH_SEMANTICS=CHAR
and I also added the listern.ora:
(SID_DESC =
     (SID_NAME=bob)
     (ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_2)
     (ENVS=LD_LIBRARY_PATH=/u01/app/oracle/product/11.2.0/dbhome_2/dg4msql/driver/lib;/u01/app/oracle/product/11.2.0/dbhome_2/lib)
     (PROGRAM=dg4msql)
tnsname.ora:
bob =
(DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
     (CONNECT_DATA = (SID = bob))
     (HS = OK)
SQL> select * from all_users@bob;
USERNAME USER_ID CREATED
public 0 08-APR-03
dbo 1 08-APR-03
guest 2 08-APR-03
INFORMATION_SCHEMA 3 13-APR-09
sys 4 13-APR-09
db_owner 16384 08-APR-03
db_accessadmin 16385 08-APR-03
db_securityadmin 16386 08-APR-03
db_ddladmin 16387 08-APR-03
db_backupoperator 16389 08-APR-03
db_datareader 16390 08-APR-03
db_datawriter 16391 08-APR-03
db_denydatareader 16392 08-APR-03
db_denydatawriter 16393 08-APR-03
14 rows selected.
The Oracle Warehouse Builder still has the same error by the conversion of character sets.
Hip

Similar Messages

  • Conversions between character sets when using exp and imp utilities

    I use EE8ISO8859P2 character set on my server,
    when exporting database with NLS_LANG not set
    then conversion should be done between
    EE8ISO8859P2 and US7ASCII charsets, so some
    characters not present in US7ASCII should not be
    successfully converted.
    But when I import such a dump, all characters not
    present in US7ASCII charset are imported to the database.
    I thought that some characters should be lost when
    doing such a conversions, can someone tell me why is it not so?

    Not exactly. If the import is done with the same DB character set, then no matter how it has been exported. Conversion (corruption) may happen if the destination DB has a different character set. See this example :
    [ora102 work db102]$ echo $NLS_LANG
    AMERICAN_AMERICA.WE8ISO8859P15
    [ora102 work db102]$ sqlplus test/test
    SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:47:01 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    TEST@db102 SQL> create table test(col1 varchar2(1));
    Table created.
    TEST@db102 SQL> insert into test values(chr(166));
    1 row created.
    TEST@db102 SQL> select * from test;
    C
    ¦
    TEST@db102 SQL> exit
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    [ora102 work db102]$ export NLS_LANG=AMERICAN_AMERICA.EE8ISO8859P2
    [ora102 work db102]$ sqlplus test/test
    SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:47:55 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    TEST@db102 SQL> select col1, dump(col1) from test;
    C
    DUMP(COL1)
    ©
    Typ=1 Len=1: 166
    TEST@db102 SQL> exit
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    [ora102 work db102]$ echo $NLS_LANG
    AMERICAN_AMERICA.EE8ISO8859P2
    [ora102 work db102]$ exp test/test file=test.dmp tables=test
    Export: Release 10.2.0.1.0 - Production on Tue Jul 25 14:48:47 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    Export done in EE8ISO8859P2 character set and AL16UTF16 NCHAR character set
    server uses WE8ISO8859P15 character set (possible charset conversion)
    About to export specified tables via Conventional Path ...
    . . exporting table                           TEST          1 rows exported
    Export terminated successfully without warnings.
    [ora102 work db102]$ sqlplus test/test
    SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:48:56 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    TEST@db102 SQL> drop table test purge;
    Table dropped.
    TEST@db102 SQL> exit
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    [ora102 work db102]$ imp test/test file=test.dmp
    Import: Release 10.2.0.1.0 - Production on Tue Jul 25 14:49:15 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    Export file created by EXPORT:V10.02.01 via conventional path
    import done in EE8ISO8859P2 character set and AL16UTF16 NCHAR character set
    import server uses WE8ISO8859P15 character set (possible charset conversion)
    . importing TEST's objects into TEST
    . importing TEST's objects into TEST
    . . importing table                         "TEST"          1 rows imported
    Import terminated successfully without warnings.
    [ora102 work db102]$ export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
    [ora102 work db102]$ sqlplus test/test
    SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:49:34 2006
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    TEST@db102 SQL> select col1, dump(col1) from test;
    C
    DUMP(COL1)
    ¦
    Typ=1 Len=1: 166
    TEST@db102 SQL>

  • Conversions between character sets when using 'exp' and 'expdp' utilities

    When I make export with exp utility with NLS_LANG environment
    variable not set, export is done with US7ASCII character set,
    but when server uses some other character set e.g. EE8ISO8859P2,
    there can be some national specific characters lost with such a conversion.
    But when I use expdp utility and have not NLS_LANG set,
    in log file there is not mentioned that export is done in other character set
    than that on the server, does it mean that it uses character set on server?

    When I make export with exp utility with NLS_LANG environment
    variable not set, export is done with US7ASCII character set,
    but when server uses some other character set e.g. EE8ISO8859P2,
    there can be some national specific characters lost with such a conversion.
    But when I use expdp utility and have not NLS_LANG set,
    in log file there is not mentioned that export is done in other character set
    than that on the server, does it mean that it uses character set on server?

  • Can a db with character set UTF8 be restored to AL32UTF8?

    Hello Everyone,
    Good Day.
    Our present production and non-production databases are configured with NLS_CHARACTERSET as UTF8. However, as we are in the process of migrating to a new server, we intend to configure the new databases with NLS_CHARACTERSET as AL32UTF8 (which is the recommended option as per our research. Moreover, came to know that for Weblogic schemas and repositories to work, NLS_CHARACTERSET must be AL32UTF8).
    As we would be restoring from a backup to the new instance created on the new server, kindly help us understand if any issues might arise while restoring due to both being different charactersets?
    Warm Regards,
    Vikram.

    Hi Robin,
    Thank you for the update. Our DB is too huge and contains many schemas to try for a data pump. Hence we had planned for a restoration which might be simpler task with lesser downtime.
    Perhaps, one option would be to create the instances with UTF character set itself and then change it once the migration activity has been completed.
    Also, could you please throw some light on the two character sets as to which one is better and why?
    Warm Regards,
    Vikram.

  • Character sets and conversions

    Hi all,
    were facing a quite complex problem, for which I'am not even able to specify were it is going wrong or what needs configuring, partly for lack of experience and partly for combining different tecnical areas from which I'm only responible for some of them.
    So I'll sketch breefly the situation, and hopefully you might give me some guidelines or hints as to where to look at.
    The setup : web application (so clients access by use of browser) on Weblogic- Linux platform, Tuxedo on Iseries , and as far as I understand some DB internally to Iseries where data is stored.
    Data is entered in the DB by use of some data-entry application that comes with the iSeries.
    The problem: consulting data by use of the web-aplication , some characters dont show up correctly , e.g. @ in email addresses, e's with accents, ...
    For the chain being "browser <-> WL <-> Tuxedo <-> DB" , the problem might be different points. But from trace beeing activated , we could see that the response going out of tuxedo to WL is not correct...
    Any hint as to what to look for, what can configuration is important, would be welcome ...
    Some sub-questions:
    - I understand Tuxedo is always "installed" in English , with no other option. This means that f.e. logs are in English.
    But can/need to define some character set?
    - Between Tuxedo <-> DB you can use som conversion tables ?
    Any help would be apreciated , were quite lost ..

    Hi,
    Given that you are running Tuxedo on iSeries, I'm guessing you are running Tuxedo 6.5 as the port for the current Tuxedo release on iSeries hasn't been released yet. Tuxedo 6.5 does not directly support multi-byte character strings. The two common buffer formats for string data in Tuxedo are STRING which doesn't support multi-byte characters, or CARRAY which does support multi-byte characters as a CARRAY is essentially a blob. Do you know what buffer type the Tuxedo application is using to send data to WebLogic Server?
    In Tuxedo 9.0 and later, direct support for multi-byte strings was added in the form of the MBSTRING buffer type. This buffer type supports multi-byte strings with a variety of character sets and encodings.
    Regards,
    Todd Little
    Oracle Tuxedo Chief Archiitect

  • Character set conversion warnings in Gtk apps

    Recently I noticed that various Gtk applications throw this warning (actually, many times, pretty much every time something in the window needs updating) when running them:
    (gimp:5803): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported
    (gvim:5697): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-1'
    These are examples with gimp and gvim, but the same goes for alunn, rox, firefox, gtk-chtheme, ...
    I tried to search various forums and google, but nobody seems to address this issue, and if, then it's along the lines "recompile everything and start with gtk2". That's not satisfactory for me. Especially, since some apps (like gimp) sometimes crash with this error.
    Some info: I run with LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8, and locales defined in locale.gen include en_US.UTF-8 and en_US ISO-8859-1, and I did generate the locales (locale-gen).
    Any help/ideas about what to do with this are appreciated.
    EDIT: couldn't it be a problem with the recent update of glibc (on 02/15)?
    Last edited by bender02 (2007-02-23 05:49:44)

    Well, talking to myself here - I just wanted to say that recent upgrade to glibc-2.5-5 seems to have solved the issue.

  • 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

  • Database character set = UTF-8, but mismatch error on XML file upload

    Dear experts,
    I am having problems trying to upload an XML file into an XMLType table. The Database is 9.2.0.5.0, with the character set details:
    SELECT *
    FROM SYS.PROPS$
    WHERE name like '%CHA%';
    Query results:
    NLS_NCHAR_CHARACTERSET          UTF8     NCHAR Character set
    NLS_SAVED_NCHAR_CS          UTF8
    NLS_NUMERIC_CHARACTERS          .,     Numeric characters
    NLS_CHARACTERSET          UTF8     Character set
    NLS_NCHAR_CONV_EXCP          FALSE     NLS conversion exception
    To upload the XML file into the XMLType table, I am using the command:
    insert into XMLTABLE
    values(xmltype(getClobDocument('ServiceRequest.xml','UTF8')));
    However, I get the error:
    ORA-31011: XML parsing failed
    ORA-19202: Error occurred in XML processing
    LPX-00200: could not convert from encoding UTF-8 to UCS2
    Error at line 1
    ORA-06512: at "SYS.XMLTYPE", line 0
    ORA-06512: at line 1
    Why does it mention UCS2, as can't see that on the Database character set?
    Many thanks for your help,
    Mark

    USC2 is known as AL16UTF16(LE/BE) by Oracle...
    Try using AL32UTF8 as the character set name
    AFAIK The main difference between Oracle's UTF8 and AL32UTF8 character set is that is the UTF8 character set does not support those UTF-8 characteres that require 4 bytes..
    -Mark

  • Import시 character set 문제, OORA-01435, IMP-00008 에러에 의해 중단되었습니다. 조언을 부탁합니다.

    안녕하세요,
    아래와 같이 import를 하려고 하는데 에러가 나면서 중단되었습니다.
    C:\temp>imp userid=system/1234 file=c:\temp\usr_lms2-TS_LMS_DEV_D1.dmp FULL=y
    에러메시지는 아래와 같습니다.
    참고로, export 했던 어떤 database에는 usr_lms2 계정이 있었고,
    import하려는 이 database에는 그 계정이 없어서 usr_lms2 계정을 생성하고 import를 실행했습니다.
    질문1: 아래의 character set과 관련된 메시지는 정상적인것인지 궁금합니다.
    질문2: ORA-01435: user does not exist라는 에러는 왜 발생할까요?
    질문3: IMP-00008: unrecognized statement in the export file 에러는 dump 화일 자체에 문제가 있다는 말인가요?
    해결방법을 알려주시면 좋겠습니다.
    Import: Release 11.2.0.2.0 - Production on 목 3월 28 10:00:38 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
    Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
    Export file created by EXPORT:V10.02.01 via conventional path
    import done in KO16MSWIN949 character set and AL16UTF16 NCHAR character set <-------- ?
    import server uses AL32UTF8 character set (possible charset conversion) <-------- ?
    export server uses UTF8 NCHAR character set (possible ncharset conversion) <-------- ?
    . importing SYSTEM's objects into SYSTEM
    . importing USR_LMS2's objects into USR_LMS2
    IMP-00003: ORACLE error 1435 encountered <-------------------- 에러
    ORA-01435: user does not exist <--------------------- 에러
    IMP-00008: unrecognized statement in the export file: <-------------------- 에러
    Import terminated successfully with warnings.
    감사합니다.

  • How to change the Character Set from AL32UTF8 to WE8DEC

    Hello!!
    I want to know how to change the character set in the database from AL32UTF8 to WE8DEC.
    I tried to use the comand ALTER DATABASE CHARACTER SET but I got an error because WE8DEC is not a superset of AL32UTF8.
    I need to import tables from a server that uses WE8DEC. So when I do the import to my server, wich has AL32UTF8 , I can't import the rows that include an Ñ.
    So I want to change the caracter set to WE8DEC. How can I do it?
    Is it needed to change the language configuration? The remote server has AMERICAN_AMERICA, and my server has MEXICAN SPANISH_MEXICO (both uses text in spanish).
    Thanks a lot!!

    When you export from WE8DEC server what did you use
    for NLS_LANG char set? And when importing?
    The export was done in another computer because I can't do the export in the server (I have 10g, and the remote server has 9i and the export is not working). In my server, when I tried to do the import, the NS_LANG value was MEXICAN SPANISH_MEXICO.WE8MSWIN1252.
    When I try to import to my database I got the error:
    import done in WE8DEC character set and AL16UTF16 NCHAR character set
    import server uses AL32UTF8 character set (possible charset conversion)
    export client uses WE8MSWIN1252 character set (possible charset conversion)
    . importing USRMCR06's objects into PRIMARIZACION
    . . importing table "CHG_FONDOS_MARZO_CD_MOR"
    IMP-00019: row rejected due to ORACLE error 12899
    IMP-00003: ORACLE error 12899 encountered
    ORA-12899: value too large for column "PRIMARIZACION"."CHG_FONDOS_MARZO_CD_MOR".
    "NOMBRE" (actual: 41, maximum: 40)
    Column 1 16623436
    Column 2
    Column 3 Pymes_1
    Column 4

  • Checking server character set

    I think this is a simple question, but for some reason I am not able to find the result.
    How can I check the server's default character set?
    We have HP-UX (unix) servers, and most databases are set to AL32UTF8/AL16UTF16.
    I thought it would be something simple like typing 'locale', but on the HP-UX box(es), it doesn't show any setting for LANG.
    I also executed 'env' and looked at all settings, but nothing seems relevant.
    Unless I explicitly set the NLS_LANG=AMERICAN_AMERICA.AL32UTF8, when I do an export, it shows:
    Export done in US7ASCII character set and AL16UTF16 NCHAR character set
    server uses AL32UTF8 character set (possible charset conversion)
    Where is it getting the US7ASCII?
    If I select * from nls_database_parameters; there is no setting like US7ASCII.
    When I do a 'man -k character', I get numerous possible commands, but none of them appear to be something that displays the default character set.
    But, as I noted above, when I run an export of our database (without setting the NLS_LANG), it shows me that the default character set is US7ASCII.
    So, how do I show this, and if you might also have any ideas how to change this to UTF8.
    Thanks.
    removed references in this posting to my linux boxes...

    The default O/S character set for Unix is 7-bit ASCII. This is element of so-called "C locale". This locale is used by all applications that do not declare themselves sensitive to user locale (i.e. they do not call setlocale() at application startup) and by all applications that have no locale parameters (LANG, or LC_xxxx) set in their environment.
    If you call 'locale' in a Unix session that has no locale environment set, the "C locale" should be reported.
    "C locale" uses US locale formatting conventions and binary collation.
    ## "Export done in US7ASCII character set and AL16UTF16 NCHAR character set
    ## server uses AL32UTF8 character set (possible charset conversion)"
    Here, US7ASCII is the default character set of an Oracle Client. It is not directly related to the default O/S character set. US7ASCII is always the default Oracle client character set on all non-EBCDIC platforms, used if NLS_LANG is not explicitly set.
    -- Sergiusz

  • 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 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
    <p>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.</p>
    <p> </p>
    <p>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.</p>
    <p> </p>
    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

  • ORA-12709: error while loading create database character set after upgrade

    Dear All
    i m getting ORA-12709: error while loading create database character set, After upgraded the database from 10.2.0.3 to 11.2.0.3 in ebusiness suit env.
    current application version 12.0.6
    please help me to resolve it.
    SQL> startup;
    ORACLE instance started.
    Total System Global Area 1.2831E+10 bytes
    Fixed Size 2171296 bytes
    Variable Size 2650807904 bytes
    Database Buffers 1.0133E+10 bytes
    Redo Buffers 44785664 bytes
    ORA-12709: error while loading create database character set
    -bash-3.00$ echo $ORA_NLS10
    /u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
    export ORACLE_BASE=/u01/oracle
    export ORACLE_HOME=/u01/oracle/PROD/db/tech_st/11.2.0
    export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
    export PERL5LIB=$ORACLE_HOME/perl/lib/5.10.0:$ORACLE_HOME/perl/site_perl/5.10.0
    export ORA_NLS10=/u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
    export ORACLE_SID=PROD
    -bash-3.00$ pwd
    /u01/oracle/PROD/db/tech_st/11.2.0/nls/data/9idata
    -bash-3.00$ ls -lh |more
    total 56912
    -rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx00001.nlb
    -rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00002.nlb
    -rw-r--r-- 1 oracle oinstall 959 Jan 15 16:05 lx00003.nlb
    -rw-r--r-- 1 oracle oinstall 984 Jan 15 16:05 lx00004.nlb
    -rw-r--r-- 1 oracle oinstall 968 Jan 15 16:05 lx00005.nlb
    -rw-r--r-- 1 oracle oinstall 962 Jan 15 16:05 lx00006.nlb
    -rw-r--r-- 1 oracle oinstall 960 Jan 15 16:05 lx00007.nlb
    -rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00008.nlb
    -rw-r--r-- 1 oracle oinstall 940 Jan 15 16:05 lx00009.nlb
    -rw-r--r-- 1 oracle oinstall 939 Jan 15 16:05 lx0000a.nlb
    -rw-r--r-- 1 oracle oinstall 1006 Jan 15 16:05 lx0000b.nlb
    -rw-r--r-- 1 oracle oinstall 1008 Jan 15 16:05 lx0000c.nlb
    -rw-r--r-- 1 oracle oinstall 998 Jan 15 16:05 lx0000d.nlb
    -rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx0000e.nlb
    -rw-r--r-- 1 oracle oinstall 926 Jan 15 16:05 lx0000f.nlb
    -rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00010.nlb
    -rw-r--r-- 1 oracle oinstall 958 Jan 15 16:05 lx00011.nlb
    -rw-r--r-- 1 oracle oinstall 956 Jan 15 16:05 lx00012.nlb
    -rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx00013.nlb
    -rw-r--r-- 1 oracle oinstall 970 Jan 15 16:05 lx00014.nlb
    -rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00015.nlb
    -rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00016.nlb
    -rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00017.nlb
    -rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00018.nlb
    -rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00019.nlb
    -rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx0001a.nlb
    -rw-r--r-- 1 oracle oinstall 944 Jan 15 16:05 lx0001b.nlb
    -rw-r--r-- 1 oracle oinstall 953 Jan 15 16:05 lx0001c.nlb
    Starting up:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options.
    ORACLE_HOME = /u01/oracle/PROD/db/tech_st/11.2.0
    System name: SunOS
    Node name: proddb3.zakathouse.org
    Release: 5.10
    Version: Generic_147440-19
    Machine: sun4u
    Using parameter settings in server-side spfile /u01/oracle/PROD/db/tech_st/11.2.0/dbs/spfilePROD.ora
    System parameters with non-default values:
    processes = 200
    sessions = 400
    timed_statistics = TRUE
    event = ""
    shared_pool_size = 416M
    shared_pool_reserved_size= 40M
    nls_language = "american"
    nls_territory = "america"
    nls_sort = "binary"
    nls_date_format = "DD-MON-RR"
    nls_numeric_characters = ".,"
    nls_comp = "binary"
    nls_length_semantics = "BYTE"
    memory_target = 11G
    memory_max_target = 12G
    control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl01.dbf"
    control_files = "/u01/oracle/PROD/db/tech_st/10.2.0/dbs/cntrl02.dbf"
    control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl03.dbf"
    db_block_checksum = "TRUE"
    db_block_size = 8192
    compatible = "11.2.0.0.0"
    log_archive_dest_1 = "LOCATION=/u01/oracle/PROD/db/apps_st/data/archive"
    log_archive_format = "%t_%s_%r.dbf"
    log_buffer = 14278656
    log_checkpoint_interval = 100000
    log_checkpoint_timeout = 1200
    db_files = 512
    db_file_multiblock_read_count= 8
    db_recovery_file_dest = "/u01/oracle/fast_recovery_area"
    db_recovery_file_dest_size= 14726M
    log_checkpoints_to_alert = TRUE
    dml_locks = 10000
    undo_management = "AUTO"
    undo_tablespace = "APPS_UNDOTS1"
    db_block_checking = "FALSE"
    session_cached_cursors = 500
    utl_file_dir = "/usr/tmp"
    utl_file_dir = "/usr/tmp"
    utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound"
    utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound/PROD_proddb3"
    utl_file_dir = "/usr/tmp"
    plsql_code_type = "INTERPRETED"
    plsql_optimize_level = 2
    job_queue_processes = 2
    cursor_sharing = "EXACT"
    parallel_min_servers = 0
    parallel_max_servers = 8
    core_dump_dest = "/u01/oracle/PROD/db/tech_st/10.2.0/admin/PROD_proddb3/cdump"
    audit_file_dest = "/u01/oracle/admin/PROD/adump"
    db_name = "PROD"
    open_cursors = 600
    pga_aggregate_target = 1G
    workarea_size_policy = "AUTO"
    optimizer_secure_view_merging= FALSE
    aq_tm_processes = 1
    olap_page_pool_size = 4M
    diagnostic_dest = "/u01/oracle"
    max_dump_file_size = "20480"
    Tue Jan 15 16:16:02 2013
    PMON started with pid=2, OS id=18608
    Tue Jan 15 16:16:02 2013
    PSP0 started with pid=3, OS id=18610
    Tue Jan 15 16:16:03 2013
    VKTM started with pid=4, OS id=18612 at elevated priority
    VKTM running at (10)millisec precision with DBRM quantum (100)ms
    Tue Jan 15 16:16:03 2013
    GEN0 started with pid=5, OS id=18616
    Tue Jan 15 16:16:03 2013
    DIAG started with pid=6, OS id=18618
    Tue Jan 15 16:16:03 2013
    DBRM started with pid=7, OS id=18620
    Tue Jan 15 16:16:03 2013
    DIA0 started with pid=8, OS id=18622
    Tue Jan 15 16:16:03 2013
    MMAN started with pid=9, OS id=18624
    Tue Jan 15 16:16:03 2013
    DBW0 started with pid=10, OS id=18626
    Tue Jan 15 16:16:03 2013
    LGWR started with pid=11, OS id=18628
    Tue Jan 15 16:16:03 2013
    CKPT started with pid=12, OS id=18630
    Tue Jan 15 16:16:03 2013
    SMON started with pid=13, OS id=18632
    Tue Jan 15 16:16:04 2013
    RECO started with pid=14, OS id=18634
    Tue Jan 15 16:16:04 2013
    MMON started with pid=15, OS id=18636
    Tue Jan 15 16:16:04 2013
    MMNL started with pid=16, OS id=18638
    DISM started, OS id=18640
    ORACLE_BASE from environment = /u01/oracle
    Tue Jan 15 16:16:08 2013
    ALTER DATABASE MOUNT
    ORA-12709 signalled during: ALTER DATABASE MOUNT...

    ORA-12709 signalled during: ALTER DATABASE MOUNT...Do you have any trace files generated at the time you get this error?
    Please see these docs.
    ORA-12709: WHILE STARTING THE DATABASE [ID 1076156.6]
    Upgrading from 9i to 10gR2 Fails With ORA-12709 : Error While Loading Create Database Character Set [ID 732861.1]
    Ora-12709 While Trying To Start The Database [ID 311035.1]
    ORA-12709 when Mounting the Database [ID 160478.1]
    How to Move From One Database Character Set to Another at the Database Level [ID 1059300.6]
    Thanks,
    Hussein

  • How to change character set to arabic in Develper suite forms 10g

    Dear all,
    Our company wants migrate oracle forms 4.5/6i applications to Oracle developer suite 10g version.
    They also want there database to upgrade from 9i to 10g.
    They gave me test machine, on which windows xp is installed and i did the following:-
    1,Installed Oracle 10g Xe edition database.
    2,Installed Oracle 10g Devloper suite(oracle forms, Oracle reports).
    3, Configured the connection of Oracle Developer suite 10g to Oracle Database 10g.
    4, Loaded Data into the 10g database. *( they are few columns like DEPARTMENT_NAME_ARB, FUNCTION_NAME_ARB which is supposed to show in arabic fonts, as it is in arabic in 9i database, now they are showing in some special characters)*
    What I would like to know is: Is there a way through which i can set characterset?
    Is it in the database in which i have to make character set change?
    Is it in the oracle developer suite application in which i have to make character set change?
    Is it in the registry in which i have to make changes?
    please help.

    Hi freinds,
    It is very encouraging to see your replies, i apologize for the late reponse, i still got no success with updating PROPS$,
    I relgiously followed all the instructions given to me by all of you. Like u could see in my previous posts
    Luckiily, i am able to insert one row at a time manaually iin arabic and in english by pressing (ALT+SHIFT).
    When i create datablocks in forms builder, i do see output in arabic.
    When i create report in group style i do see ouptput in arabic.
    i have thousands of rows(in GB's) which needs to be inserted in this new database 10g XE edition (downloaded from oracle)
    I have attempted multiple times insertion of data by just running script, or simply copying numerous insert statement rows from notepad to sql*plus, unluckily it alwayz retreived the special charachters rather than retreiving arabic characters.
    Is there a way to insert data in this new oracle 10g xe editon database via oracle developer suite 10g forms/reports?
    Do I have to use inbuilt data load/unload utilities in oracle 10g xe edition?
    Do I have to install sql*loader separately to load the data?
    Do you think TOAD can help in this?
    Could you please tell me how to add snap shots in this post?(user10947262)
    Here are the following details of National Language Parameter Value
    Before
    NLS_CALENDAR     GREGORIAN
    NLS_CHARACTERSET     AL32UTF8 (IS this multibyte (UTF-8) character set SARAH?)
    NLS_COMP     BINARY
    NLS_CURRENCY     $
    NLS_DATE_FORMAT     DD-MON-RR
    NLS_DATE_LANGUAGE     AMERICAN
    NLS_DUAL_CURRENCY     $
    NLS_ISO_CURRENCY     AMERICA
    NLS_LANGUAGE     AMERICAN
    NLS_LENGTH_SEMANTICS     BYTE
    NLS_NCHAR_CHARACTERSET     AL16UTF16
    NLS_NCHAR_CONV_EXCP     FALSE
    NLS_NUMERIC_CHARACTERS     .,
    NLS_SORT     BINARY
    NLS_TERRITORY     AMERICA
    NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
    NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_TIME_FORMAT     HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
    After
    NLS_CALENDAR     GREGORIAN
    NLS_CHARACTERSET     AL32UTF8
    NLS_COMP     BINARY
    NLS_CURRENCY     ر.س.
    NLS_DATE_FORMAT     DD/MM/RR
    NLS_DATE_LANGUAGE     ARABIC
    NLS_DUAL_CURRENCY     ر.س.
    NLS_ISO_CURRENCY     SAUDI ARABIA
    NLS_LANGUAGE     ARABIC
    NLS_LENGTH_SEMANTICS     BYTE
    NLS_NCHAR_CHARACTERSET     AL16UTF16
    NLS_NCHAR_CONV_EXCP     FALSE
    NLS_NUMERIC_CHARACTERS     .,
    NLS_SORT     ARABIC
    NLS_TERRITORY     SAUDI ARABIA
    NLS_TIME_FORMAT     HH12:MI:SSXFF PM
    NLS_TIMESTAMP_FORMAT     DD/MM/RR HH12:MI:SSXFF PM
    NLS_TIMESTAMP_TZ_FORMAT     DD/MM/RR HH12:MI:SSXFF PM TZR
    NLS_TIME_TZ_FORMAT     HH12:MI:SSXFF PM TZR
    Certainly Christian, i dont want to screw my oracle 10g database xe edition software and installation, and i agree and hope with this that creating new database and doing exporting and importing will work for me. (XE edition doesnt give option to create new database, i need to install 10g release2 media pack from edelivery)
    However, with the above informatiion provided, Is it really needed?
    Please help me.
    Thanks and Regards

Maybe you are looking for

  • Fn-key not working on NB305 after upgrade of Win7

    FN-key stopped showing flashcrads on a NB305-N410WH after an upgrade of Win7 Ultimate was applied to the standard Win7 Starter. I reinstled with latest flashcards utility (2.00.43) and TVAP (1.2.33) but the problem persists. The only possibility to o

  • Create blank white HD menu background

    How can i do this in Encore CS5? I have reviewed the selections in the library, but i cannot figure out how to do this. I often use the blank HD selection which gives me the black background. Is there a way to transform this to a white background? th

  • Sports Team Editor: How do I get the players to display in the sports theme?

    How do I get the players to display in the sports theme video? I entered the team and players using the sports team editor. Then clicked done and update. But when I play the video only the first players profile shows up. I have the rest of the video

  • Design View differs from Live view problem

    I have Dreamweaver CS5.5 with Mac OS 10.7.3 on an iMac. I have the same set-up on a Macbook Pro 17 The problem is that the Design view is showing different fonts and not picking up layout as per CSS style but the Live view is all correct. All is fine

  • Dovecot is killing my internet access. How do I stop dovecot?

    We recently changed servers and had a lot of issues with Mozilla Thunderbird Email. Now I find my folks cannot access our website because something called dovecot is accessing the server and not terminating -draining the resources on the server. I wi