Std::string NLS_LANG character sets

I'm an OCI user but not a pure one. Because I use the free available OTL (Oracle Template Library) from S.Kuchin which is a wrapper around OIC I hope this not off topic here.
The library offers the possibility to read database strings from VARCHAR2 fields to
a std::string. I know that oracle does character converting at client side controlled
via NLS_LANG environment variable.
It's clear to me that reading database strings to std::string is no problem for
one byte character sets liike ISO-8859-1. But how about when I let point NLS_LANG
to UTF-8 or chinese character set e.g. ZHT16BIG5 ?
Is it still safe to read the result to a std::string ?
For example I have a database with default characterset AMERICAN_AMERICA.WE8ISO8859P15. I stored some German umlaut in some
table. I wrote a small program using OTL and set NLS_LANG to UTF8 on client side.
I fetched the data from server to client, stored the data in a std::string, pushed them in a file and yes the data were stored as UTF8.
Is it really so simple or is it dangerous to read the UTF8-converted data to
std::string ? Wat is the common rule ? When may and when may I not read the data
to std::string ?

Hello,
I think you'll have more accurate answer in the Globalization Support Forum:
Globalization Support
Best regards,
Jean-Valentin

Similar Messages

  • Sql developer vs nls_lang/character set

    Hi
    I've been trying to change the character set for sql developer but I can't seem to get it done.
    I've tried:
    <ul>
    <li>regedit: NLS_LANG=AMERICAN_AMERICA.AL32UTF8
    <li>Windows env: NLS_LANG=AMERICAN_AMERICA.AL32UTF8
    <li>dos env: set NLS_LANG=AMERICAN_AMERICA.AL32UTF8
    </ul>
    and still it is not showing in AL32UTF8, while sqlplus and sqlplusw on the same computer do show the correct character set
    What am I missing?
    Geert

    Duh, nobody ever checks out Preferences?
    That trick's for v1.0; NLS Parameters can be found under the Database node since...
    No guarantee that would enable the desired character set in the desired places, but you can try to change the Encoding under Environment too.
    Regards,
    K.

  • Jolt STRING local character set

    Our application sends data containing non-latin characters in FML32 STRING fields. What I found in documentation is:
    For localization, the Jolt Class Library package relies on the conventions of the Java language and the Oracle Tuxedo system. Jolt transfers Java 16-bit Unicode characters to the JSH. The JSH provides a mechanism to convert Unicode to the local character set.
    So how does JSH know the "local character set"?

    tutti_frutti:
    You may want to use the following:
    String input = textfield.getText();
    int len = 0;
    char curr_char;
    if(input != null) {
        len = input.length();
        for( int i = 0; i < len; i++) {
            curr_char = input.charAt(i);
            if(Character.UnicodeBlock.of(curr_char) == Character.UnicodeBlock.ARABIC) {
                // Do something
            else if(Character.UnicodeBlock.of(curr_char) == Character.UnicodeBlock.BASIC_LATIN) {
                // Do some other thing
    }

  • How to change the Forms and Reports's NLS_LANG character set on OAS

    Hi,
    I'm having problems with the OAS10g's actual character set, when displaying a report made with Reports Builder 10g who has the letter "ñ" it displays "ñ " with a blank space at the final so i need to change this character set for one that suits this requirement.
    which file or files should i change ??
    could this change affect something else, for example another product in my OAS ??
    Regards
    Carlos

    I have this Forms and Reports Application in Brazilian Potuguese. What I do at new installations is:
    1. Open this file: <MiddlewareOracleHome>/forms/server/default.env and add the NLS parameters below the FORMS_PATH definition:
    FORMS_PATH=D:\Oracle\home207middle\forms;D:\MYENV\Exe;D:\MYENV\Imagens
    NLS_LANG=BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252
    NLS_NUMERIC_CHARACTERS=,.2. Open this file: <MiddlewareOracleHome>/reports/conf/<your_report_server_name>.conf and create an "environment" section with the NLS variables:
       <environment id="MYENV">
          <envVariable name="REPORTS_PATH" value="D:\MYENV\Exe;D:\MYENV\Imagens"/>
          <envVariable name="NLS_LANG" value="BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252"/>
          <envVariable name="NLS_DATE_FORMAT" value="DD/MM/YYYY"/>
          <envVariable name="NLS_NUMERIC_CHARACTERS" value=",."/>
       </environment>For this one to work, the application must set RP2RROREPORTSENV=MYENV before launching the report.

  • Western european an Polish character set

    Dear gurus,
    I 'm work on oracle database 10R2 server with Western European character set. We now want to include polish character to suit a new customer. Inorder to keep our wester eurpean languages (English, danish, swedish etc) and the new polish, I converted the database server and the window webserver client to Unicode UTF8 but I am unable to retrieve some polish characters such as ( ą ć ę ł ń ś ż ź) as they are display differently from the original characters.
    If the know the best character set/how to configure the database to support both western european (not only english) and polish character sets please share your view.
    regards

    Before you can determine whether the characters are displayed correctly, you need to determine that they are stored correctly.
    The dump function is useful for this
    For example if I dump this entire string
    select dump('ą ć ę ł ń ś ż ź') from dual;
    I get the following
    Typ=96 Len=23: 196,133,32,196,135,32,196,153,32,197,130,32,197,132,32,197,155,32,197,188,32,197,186
    and dumping individual characters, eg
    select dump('ą') from <yourtable>l;
    Typ=96 Len=2: 196,133
    I do this test with OracleSqlDeveloper running on the Database Server which has a UTF8 characterset
    Check out the globalisation guide. The basic principle here is that the NLS_LANG character setting on your client should be the same as on your server.
    eg if you are using a windows client and your server NLS_LANG is set to AMERICAN_AMERICA.UTF8 and teh NLS_LANG setting in the windows registry is AMERICAN_AMERICA.ASCII7, then you would need to change the NLS_LANG setting in the windows registry to AMERICAN_AMERICA.UTF8.
    This would then resolve the issues with client display.
    So,the steps here are (and in order)
    1) Ensure your Data is stored correctly on the server (Insert on server )
    2) Ensure your Data is retrieved correctly on the server(Retrieve on server)
    3) Ensure your data is displayed correctly on the Client(Retrieve on Client)
    That should hopefully resolve your problem. The Globalisation guide as mentione dearlier is your place of reference

  • Arabic text shows junk in database character set

    Hi,
    Workion EBS Ver11.5.0
    NLS_CHARACTERSET :AR8ISO8859P6
    NLS_LANG : AMERICAN_AMERICA.WE8ISO8859P1
    i have a trial balance report, in that description text is displaying like this ????? ??? ?????? - ???? ????? ???
    to rectify this, what steps should i do to display in arabic text and it should support both arabic and english.
    could anyone please help me in this.
    Thanks and Regards
    Khaleel

    First you should make sure your client machine is able to display arabic data.
    Second you likely need to change NLS_LANG character set part to the right character set, possibly AR8ISO8859P6 or another character set compatible with your database character set.
    Please read carefully OTN NLS_FAQ http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm.
    If you are working with Oracle E-Businees Suite, there may be some additional rules to configure application server to display correctly arabic data.

  • 한글이 ??? 로 DISPLAY 되는 경우(CHARACTER SET)

    제품 : SQL*PLUS
    작성날짜 : 1996-07-02
    한글이 ??? 로 DISPLAY 되는 경우(CHARACTER SET)
    =============================================
    Oracle Tools(SQL*Plus, Forms 30, Forms 40, Reports 20 등)을 이용하여 한글
    DATA를 조회할 때 ???로 출력되는 경우 해결 방법.
    DATABASE는 SQL COMMAND 'CREATE DATABASE'를 포함하는 STATEMENT를 수행할
    때 만들어지는데 우리가 그 STATEMENT를 수행하기 앞서 고려해야 할 사항 중의
    하나가 DB CHARACTERSET이다.
    DB를 CREATE할 때 DATABSE CHARACTERSET을 명시해야만 하는데, 한번 선택되고
    난 후에는 CHARACTER SET을 변경하는 것은 쉽지가 않다.
    DATA DICTIONARY에 있는 DATA를 포함해서 모든 DATA는 선택된 CHARACTERSET에
    의해 입출력 되기 때문에 USER가 다른 CHARACTERSET으로 ACCESS한다면 한글 데이
    타가 ???로 출력된다.
    또한, 분산 DB 환경이나 UPGRADE할 경우에는 DATABASE CHARACTERSET이 같아야
    하므로, 사용자들은 DATABASE의 CHARACTERSET을 알아 두어야 한다.
    < 현재 DATABASE 의 CHARACTERSET 확인 및 변경 >
    1. 데이타베이스 CHARACTERSET 확인
    $ sqldba lmode=y
    SQLDBA> connect internal
    SQLDBA> select * from v$nls_parameters;
    PARAMETER VALUE
    NLS_CHARACTERSET KO16KSC5601 (or US7ASCII)
    (A)
    2. 환경 변수의 NLS_LANG 확인
    $ env
    NLS_LANG=American_America.US7ASCII
    (B)
    위의 (A)와 (B)가 동일한 경우에만 한글 데이타 처리에 문제가 없으며, 이것이
    서로 다른 상태에서 한글 데이타를 조회할 경우에는 ??? 로 출력 된다.
    3. CHARACTERSET을 일치시키는 방법
    * NLS_LANG 환경 변수를 변경하여 일치시키는 방법
    <UNIX>
    Bourne shell, k-shell을 사용하는 경우 .profile을 수정한다.
    NLS_LANG = American_Amerca.KO16KSC5601; export NLS_LANG
    c-chell을 사용하는 경우 .cshrc 혹은 .login 수정
    setenv NLS_LANG American_America.KO16KSC5601
    수정 후 다시 $env를 실행하여 변경되었는지 확인한다.
    <WINDOWS 3.1>
    C:\WINDOWS\ORACLE.INI 수정
    NLS_LANG=American_America.KO16KSC5601
    WINDOW 재기동
    <WINDOWS 95>
    WINDOWS 95에서는 NLS_LANG이 ORACLE.INI에 들어있지 않고
    REGISTRY에 기록되므로 REGISTRY EDITOR를 이용하여 수정해야 한다.
    MS DOS 창으로 나가서 REGEDIT.EXE 실행
    또는
    시작 -> 실행 -> regedit -> HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE
    오른쪽 마우스 버튼을 이용하여 NLS_LANG을 수정한다.
    REGISTRY 변경 후에 PC를 REBOOTING 할 필요는 없습니다.
    <WINDOWS NT>
    WINDOWS NT 에서도 WINDOWS 95의 경우와 마찬가지로 REGISTRY에 기록된
    정보를 변경해 주면 됩니다. 다음과 같이 합니다.
    DOS 창에서 REGEDT32.EXE 실행
    HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE 선택
    메뉴를 선택하여 NLS_LANG을 수정
    * 서로 다른 character set 을 갖는 DB를 access 하는 client에서는 다음과
    같은 setting 을 하면 편리합니다.
    예를 들어서 SERVER의 character set이 US7ASCII이고 PC의 NLS_LANG이
    American_America.KO16KSC5601과 같이 서로 다르게 설정되어 있는 경우
    다음을 각 client의 환경에 추가하면 한글 문제가 해결됩니다.
    ORA_NLS_CHARACTERSET_CONVERSION=NO_CHARACTER_SET_CONVERSION

    두 디비가 다른 캐랙터 셋을 쓴다고 해도
    디비 자체에는 문제가 없다고 보는데 말이죠..
    두 플렛폼을 비교한번해보시고요.
    그래도 문제가 생긴다면 님 말씀 대로 바꿔보심이.
    위에건 그냥 보시라는거고
    중요한건 imp,exp할때 약간 조정이 필요할거 같은데 말이죠.

  • Problem with character set (ubuntu linux)

    hello everyone.
    I 'have already installed oracle-xe-universal_10.2.0.1-1.1_i386 in ubuntu.
    The problem is that greek characters from the db appear like ??????.
    How can i set the right nls_lang character set to solve the problem in ubuntu linux?
    Thank you in advance!

    Character code point translation is in the realm of the client, try setting NLS_LANG environment variable.
    If your client programs handle UTF8, as do many linux utilities, that is the best choice, set your <language>_<locale>.<characterset>, i.e.
    export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
    Or french_france, or german_germany ... depends on the locale you want to use. Try a `putty` session to the host, the terminal can be set for many different character sets, i.e. ISO8859-<n> a.k.a. the WE8<n> or Western European, UTF, etc. under Window/Translation.
    Try a few select ... from dual; statements in sqlplus with a literal, and different unicode values- the unistr() and dump() functions can come in quite handy.
    select unistr('\ac20 euro' ) from dual;
    ... € euro ...
    select dump( unistr('\ac20 euro' ) ) from dual;
    ... <ascii codes for the character values> ...
    select dump( unistr('\ac20 euro' ),16 ) from dual; -- this one for hex dump

  • USING THE CHARACTER SET SCANNER

    How can I find and download the Character Set Scanner utility mentioned in MetaLink document # 66320.1.
    Thanks
    Pratap

    I would like to know if there exists a database character set
    scanner for ORACLE816. If not, can I use the ORACLE817 scanner
    to scan my ORACLE816 database?Check out the Globalization Support Home page
    http://technet.oracle.com/tech/globalization/content.html and go
    to the scanner download page for more info.
    Is it important to use a scanner if I am converting my database
    from, say, WE8ISO8859P1 character set to UTF8? Yes definitely. The scanner will identify
    1. If you have any invalid WE8ISO8859P1 data in your database ,
    these will be lost during the character set conversion process.
    2. If there are any data cell expansions, so that column widths
    can be expanded to cater for the new sizing.
    3. Area of possible character set conversion and truncation of
    data.
    Can I assume that a database UTF8 will automatically store all
    my original characters correctly?UTF8 can store all the characters from WE8ISO8859P1 ,and it can
    be stored correctly if your NLS configuration is correct . The
    key is your client NLS_LANG character set setting .
    I have a client with NLS_LANG set to UFT8. When I exported my
    database (in WE8ISO8859P1) from my client, the export was done
    in the client's setting i.e. UTF8. Can I assume that the
    conversion was done at the time of export itself?Yes, your assumption is correct.

  • 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

  • How to set Multi Byte Character Set ( MBCS ) to Particular String In MFC VC++

    I Use Unicode Character Set in my MFC Application ( VC++) .
    now i get the output   ठ桔湡潹⁵潦⁲獵 (like this )character and i want to convert this character in english language (means MBCS),
    But i need Unicode to My Applicatiion. when i change the Multi-Byte Character set It give Correct output in English but other Objects ( TreeCtrl Selection ) will perform wrongly .  so i need to convert the particular String to MBCS
    how can i do that ? In MFC

    I assume your string read from your hardware device is an plains "C" string (ANSI string). This type of string has one byte per character. Unicode has two bytes per character.
    From the situation you explained I'd convert the string returned by the hardware to an Unicode string using i.e. MultibyteTowideChar with CP_ACP. You may also use mbstowcs or some similar functions to convert your string to an Unicode string.
    Best regards
    Bordon
    Note: Posted code pieces may not have a good programming style and may not perfect. It is also possible that they do not work in all situations. Code pieces are only indended to explain something particualar.

  • How to know the existing NLS_LANG and Character Set

    Dear all
    How can I know about the existing NLS_LANG and Character set setting for Oracle 8 (Unix platform)
    Thank you
    Kwan

    You can see this from the following
    NLS_DATABASE_PARAMETERS (i think it is how database was created)
    NLS_INSTANCE_PARAMETERS (this instance)
    NLS_SESSION_PARAMETERS (this you can set just for your login session).
    HTH
    Srinivasa Medam

  • Validate that a string is composed from a defined character set

    Hi experts,
    I need to validate that a string enetered as parameter is composed of the following character set :
    26 alphabets (both in capital or lower case), a “’” (like O’Brien), a blank between characters like (Mc Donald). So the total valid characters on any of these fields will be 54.
    could You provide with an efficient code ?
    Plz Help....
    rewards gauranteed........

    Hi,
    Check the below code.
    data: var(52) type c Value  'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'.
    data: v1(14) type c value 'welcome to SDN'.
    data: v2 type i.
    data: v3 type i.
      v3 = 0.
      v2 = STRLEN( v1 ).
      do v2 times.
       if v1+v3(1) = space .
        write:/ 'test contains character space'.
       elseif v1+v3(1) ca var.
        write:/ 'test'.
       elseif v1(v3) = '/'.
        write:/ 'test contains character /'.
       endif.
         v3 = v3 + 1.
      enddo.
    Regards,
    Shravan G.

  • Character set migration error to UTF8 urgent

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

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

  • Ora-12704: character set mismatch

    I'm trying to insert string data into a nvarchar2 column using jdbc and I keep getting the error, ora-12704: character set mismatch. How do I avoid this without using the translate function? I believe my nls variables are all set correctly. Our software will eventually be in Korean.

    Both my database and national character sets are UTF8.
    We are trying to design a system
    that supports internationalization. Majority
    of our customers will be using English but we do have Korean customers. All their data will be in korean. It is my understanding (and I could be wrong) that the korean character set is varying multi-byte. This understanding has lead me to believe I need to define my "character" columns as nchar and nvarchar2. Is this assumption wrong?
    Also, my nls_lang environment variable is AMERICAN_AMERICA.UTF8. I'm currently running Oracle 8.1.6. We have received 8.1.7 but I haven't upgraded yet.
    Thanks in advance!

Maybe you are looking for

  • Routing email from exchange 2007 to 2010 .

    Although this is an hypothetical question but still would be a great help if anyone could answer this :  " How email routing takes place from exchange 2007 user to exchange 2010 user. I have exchange 2007 and 2010 ,provided i am using single forest w

  • Weird Things a Happnin

    My system is driving me buggy. Ran DU and still nada. What's happening is when I attempt to stretch out a window it stretches out real slooooooooooow, then stops where I let my mouse button up. Then the same happens when I attempt to shrink a window,

  • Lenovo X200 refuses to go to sleep

    Hi,  I am having problems with my Lenovo X200 refusing to go to sleep. When I hit Fn-F4 or choose sleep from the menu, the screen goes black, the computer fan/harddisk noise goes down just as if it is going to sleep, it beeps and the moon lights up.

  • Program Logic for showin number of red lines on the o/p screen?

    Hi I have an output list wherein I am settin clours on the output screen based on certain conditions like if say 2 values in my final internal table doesn't match then I am settin the colour to red also green is set. My requirement is that I want to

  • Canon RAW not woking since updating to yosemite

    Since updating to Yosemite which also installed iPhoto 9.6 my Canon RAW files are not opening. Jpeg works just fine but the RAW show either all black or just a portion of the image shows. Any ideas?