May i use nls_charset12 to convert character set before executeQuery()?

i got a problem for the db nls character set
isn't us7ascii, so while retreiving data from database the data stored in ResultSet is changed to UTF-8 format. thus, my question is - how to convert character set before my executuing the method
executeQuery() or any other methods would be appreciated.
thanks in advice,

This is Tommy. I saw your post on Oracle Forum. Can you give me the classes12.zip, classes12_g.zip, and nls_charset12.zip ?!
Thx in advance !!
Tommy fromTaiwan ( July 3, 2001 )

Similar Messages

  • Flat File Load Issue - Cannot convert character sets for one or more charac

    We have recently upgraded our production BW system to SPS 17 (BW SP19)
    and we have issues loading flat files (contain Chinese, Japanese and
    Korean characters) which worked fine before the upgrade. The Asian
    languages appear as invalid characters (garbled) as we can see in PSA. The Character Set
    Settings was previously set as Default Setting and it worked fine until
    the upgrade abd we referred to note 1130965 and with the code page 1100
    the load went through (without the Cannot convert character sets for one or more characters error) however the Asian language characters will appear
    as invalid characters. We tried all the code pages suggested in the note e.g.
    4102, 4103 etc on the info packages but it did not work. Note that the
    flat files are encoded in UTF-8.

    I checked lower case option for all IO
    When i checked the PSA failed log no of records processed is "0 of 0" my question is with out processing single record system is througing this error message.
    When i use same file loading from local workstation no error message
    I am thinking when  I FTP the file from AS/400 to BI Application Server(Linex) some invalid characters are adding but how can we track that invalid char?
    Gurus please share your thoughts on this I will assign full points.
    Thanks,

  • Cannot convert character sets for one or more characters

    Hello,
    Issue:
    Source File:   Test.csv
    Source file dropped on application server as csv file via FTP
    Total records in csv file 102396
    I can able to load only 38,000 records after that I am getting error message  " convert character sets for one or more characters"  while loading into PSA .
    If i load same csv file from local workstation I am not getting any error message I can able to load total 102396 records.
    I am guessing while FTP the file into Application server some invalid codes adding?
    But I am FTP 7 files,  out of 7 I am unable to load only 1 file.
    Anybody have faced this kind of problem please share with me I will assign full points
    Thanks

    I checked lower case option for all IO
    When i checked the PSA failed log no of records processed is "0 of 0" my question is with out processing single record system is througing this error message.
    When i use same file loading from local workstation no error message
    I am thinking when  I FTP the file from AS/400 to BI Application Server(Linex) some invalid characters are adding but how can we track that invalid char?
    Gurus please share your thoughts on this I will assign full points.
    Thanks,

  • Cannot convert character sets for one or more characters Error message

    Hello,
    I am getting this error message "Cannot convert character sets for one or more characters" when i try to transfer the data from Application server file as CSV to PSA.
    Using T-code AL11
    Under SAP Directory I open my file I  can able to see all contents of my file right?
    But i can't able to see all my data because of this I am getting ths error message?
    I am loading Master data attribute
    Is there any limitation on record length?
    Please share your thought..
    Thansk

    Which length should not exceed 60.
    When i load the same file from local workstation I can able to load no error message
    Why I am getting if i load same file from application server?
    Thanks

  • Convert character sets for one or more characters

    Hello,
    Issue:
    Source File: Test.csv
    Source file dropped on application server as csv file via FTP
    Total records in csv file 102396
    while loading into PSA  I can able to load only 38,000 records after that I am getting error message " convert character sets for one or more characters" .
    If i load same csv file from local workstation I am not getting any error message I can able to load total 102396 records.
    Anybody have faced this kind of problem please share with me I will assign full points
    Thanks

    Hi,
    check
    Flatfile Issue
    Regards,
    Arek

  • How to convert character sets???

    I need to load a CLOB from a BFile, the BFile is in an (HP-UX) US7ASCII character set and the database is UTF8. I need to load the CLOB using dbms_lob.loadfromfile but can't find any info on how to convert the US7ASCII file into a UTF8 CLOB.
    HELP!!!
    --Joan Armstrong                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Joan,
    I don't know if this will help with conversion of you BFILE, but at
    http://www.xml.com/lpt/a/2000/04/26/encodings/xmlparser.html
    and at
    http://xmlsoft.org/encoding.html
    there is some information on conversion to UTF8.
    Hope it helps. Let us know.
    Dave

  • Import error converting character set

    Hi there, the first time i ever post something, so i hope i give enough information so my question can be answered.
    I have an oracle 8.1.6 database on Windows NT4. On the same machine i have installed Designer 6.
    Everything is working just fine i just can't import a dump file made from repository 6. It's not a full dump, so i first created a whole new repository.
    Now, when i want to import the dump file in command prompt, using the imp.exe (present in C:\<oracle_home>\bin), the next error occurs:
    IMP-00069: Could not convert to environment national character set's handle
    IMP-00000: Import terminated unsuccessfully.
    As the import is due to start, it gives the following message:
    import done in WE8iSO8859P1 character set and WE8IS08859P1 NCHAR character set.
    Then the error occurs.
    Now i wonder if this can be solved. I cannot see in the dump file what character set was used there. I did not make the export myself. Is there a way that i can convert the character set in the dumpfile or something? Or should i solve this problem by making changes in the database?
    Thx for your help, i am trying to solve this problem myself for over a week now and i'm getting tired of it.

    Hi friend,
    Same Problem i have faced, and i found that this is due to only the Version mismatch, u attempting to import data from higher version to lower one.
    Just check at ur end also.
    Bye
    Tehzeeb Ahmed

  • ADADMIN Convert Character Set CUSTOM_TOP

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

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

  • Importing converts character set

    Hello, everyone. I'm exporting from Windows 8.1.5 and importing into Linux 8.1.6. Both servers use character set WE8ISO8859P1. But when I import, I get this:
    Export file created by EXPORT:V08.01.05 via direct path
    import done in US7ASCII character set and US7ASCII NCHAR character set
    import server uses WE8ISO8859P1 character set (possible charset conversion)
    export client uses WE8ISO8859P1 character set (possible charset conversion)
    export server uses WE8ISO8859P1 NCHAR character set (possible ncharset conversio
    n)
    The import server originally was set to US7ASCII but I changed it using ALTER DATABASE CHARACTER SET and I've set NLS_LANG=.WE8ISO8859P1 on the import server.
    Suggestions? Your help is much appreciated!
    John

    Nothing is jumping out at me in terms of incorrect settings. Where did you specifically run the import from, Windows or Linux and from what tool Net8 etc? Are you sure NLS_LANG on Linux is now WE8ISO8859P1?

  • Use of UTF8 and AL32UTF8 for database character set

    I will be implementing Unicode on a 10g database, and am considering using AL32UTF8 as the database character set, as opposed to AL16UTF16 as the national character set, primarily to economize storage requirements for primarily English-based string data.
    Is anyone aware of any issues, or tradeoffs, for implementing AL32UTF8 as the database character set, as opposed to using the national character set for storing Unicode data? I am aware of the fact that UTF-8 may require 3 bytes where UTF-16 would only require 2, so my question is more specific to the use of the database character set vs. the national character set, as opposed to differences between the encoding itself. (I realize that I could use UTF8 as the national character set, but don't want to lose the ability to store supplementary characters, which UTF8 does not support, as this Oracle character set supports up to Unicode 3.0 only.)
    Thanks in advance for any counsel.

    I don't have a lot of experience with SQL Server, but my belief is that a fair number of tools that handle SQL Server NCHAR/ NVARCHAR2 columns do not handle Oracle NCHAR/ NVARCHAR2 columns. I'm not sure if that's because of differences in the provided drivers, because of architectural differences, or because I don't have enough data points on the SQL Server side.
    I've not run into any barriers, no. The two most common speedbumps I've seen are
    - I generally prefer in Unicode databases to set NLS_LENGTH_SEMANTICS to CHAR so that a VARCHAR2(100) holds 100 characters rather than 100 bytes (the default). You could also declare the fields as VARCHAR2(100 CHAR), but I'm generally lazy.
    - Making sure that the client NLS_LANG properly identifies the character set of the data going in to the database (and the character set of the data that the client wants to come out) so that Oracle's character set conversion libraries will work. If this is set incorrectly, all manner of grief can befall you. If your client NLS_LANG matches your database character set, for example, Oracle doesn't do a character set conversion, so if you have an application that is passing in Windows-1252 data, Oracle will store it using the same binary representation. If another application thinks that data is really UTF-8, the character set conversion will fail, causing it to display garbage, and then you get to go through the database to figure out which rows in which tables are affected and do a major cleanup. If you have multiple character sets inadvertently stored in the database (i.e. a few rows of Windows-1252, a few of Shift-JIS, and a few of UTF8), you'll have a gigantic mess to clean up. This is a concern whether you're using CHAR/ VARCHAR2 or NCHAR/ NVARCHAR2, and it's actually slightly harder with the N data types, but it's something to be very aware of.
    Justin

  • Convert custom character set of nonunicode system to standard character set

    hi all,
    I'm a BI consultant and have the following problem:
    we want to load attribute data (products, customers,...) from R3 into BI via standard extractors.
    R3 is a non-unicode system, and some products (or customers) use a custom character set Z2.
    When we extract this data to BI (a unicode system) we get an error (tRFC) saying he can't confert certain values. SAP says that he can't convert character set Z2 to the standard character set 4102.
    Converting the R3 system to a unicode system would be the solution,but is not an option... unfortunatly...
    Please advice, give gidelines,... because this problem is really a showstopper for our project...
    Thx!!!
    Joke

    hi joke,
    i am providing some  links pls chk them . I think they will be help full for you.
    www.sap-press.de/katalog/buecher/htmlleseproben/gp/htmlprobID-149 - 69k
    www.sap-press.de/download/dateien/1240/sappress_unicode_in_sap_systems.pdf
    http://209.85.207.104/search?q=cache:y__bQrnsix0J:https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f5130af2-0a01-0010-c092-a6d44eadd153convertcustomcharactersetofnonunicodesystemtostandardcharacterset%2B+abap&hl=en&ct=clnk&cd=7&gl=us
    https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/efd1dd90-0201-0010-e1b0-8437c998cd79
    www.redbooks.ibm.com/redpapers/pdfs/redp4189.pdf
    thanks
    karthik

  • Crystal XI R2 exporting issues with double-byte character sets

    NOTE: I have also posted this in the Business Objects General section with no resolution, so I figured I would try this forum as well.
    We are using Crystal Reports XI Release 2 (version 11.5.0.313).
    We have an application that can be run using multiple cultures/languages, chosen at login time. We have discovered an issue when exporting a Crystal report from our application while using a double-byte character set (Korean, Japanese).
    The original text when viewed through our application in the Crystal preview window looks correct:
    性能 著概要
    When exported to Microsoft Word, it also looks correct. However, when we export to PDF or even RPT, the characters are not being converted. The double-byte characters are rendered as boxes instead. It seems that the PDF and RPT exports are somehow not making use of the linked fonts Windows provides for double-byte character sets. This same behavior is exhibited when exporting a PDF from the Crystal report designer environment. We are using Tahoma, a TrueType font, in our report.
    I did discover some new behavior that may or may not have any bearing on this issue. When a text field containing double-byte characters is just sitting on the report in the report designer, the box characters are displayed where the Korean characters should be. However, when I double click on the text field to edit the text, the Korean characters suddenly appear, replacing the boxes. And when I exit edit mode of the text field, the boxes are back. And they remain this way when exported, whether from inside the design environment or outside it.
    Has anyone seen this behavior? Is SAP/Business Objects/Crystal aware of this? Is there a fix available? Any insights would be welcomed.
    Thanks,
    Jeff

    Hi Jef
    I searched on the forums and got the following information:
    1) If font linking is enabled on your device, you can examine the registry by enumerating the subkeys of the registry key at HKEY_LOCAL_MACHINEu2013\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink to determine the mappings of linked fonts to base fonts. You can add links by using Regedit to create additional subkeys. Once you have located the registry key that has just been mentioned, from the Edit menu, Highlight the font face name of the font you want to link to and then from the Edit menu, click Modify. On a new line in the dialog field "Value data" of the Edit Multi-String dialog box, enter "path and file to link to," "face name of the font to link".u201D
    2) "Fonts in general, especially TrueType and OpenType, are u201CUnicodeu201D.
    Since you are using a 'true type' font, it may be an Unicode type already.However,if Bud's suggestion works then nothing better than that.
    Also, could you please check the output from crystal designer with different version of pdf than the current one?
    Meanwhile, I will look out for any additional/suitable information on this issue.

  • 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

  • Why that database Character set is required

    character set is optional keyword while we create database
    manually.
    even If I didn't give character set it has taken itself automatically. why this is used for?
    if we change the character using commands what will be the response.
    let me.. know pls..
    thank u

    Hi,
    From Oracle documentation :
    Oracle's National Language Support (NLS) architecture allows you to store, process, and retrieve data in native languages. It ensures that database utilities and error messages, sort order, date, time, monetary, numeric, and calendar conventions automatically adapt to the native language and locale.
    In some cases, you may wish to change the existing database character set. For instance, you may find that the number of languages that need to be supported in your database have increased. In most cases, you will need to do a full export/import to properly convert all data to the new character set. However, if, and only if, the new character set is a strict superset of the current character set, it is possible to use the ALTER DATABASE CHARACTER SET statement to expedite the change in the database character set.
    The target character set is a strict superset if and only if each and every codepoint in the source character set is available in the target character set, with the same corresponding codepoint value.
    Paolo

  • 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

Maybe you are looking for