DB Characterset Problem

Dear All,
Please let me to know how to find the current database characterset.
Please also advice me how to change db charset, pre-requesits and its steps.
I will be very thakful to you all.
Aqeel Nawaz

Hi,
Please let me to know how to find the current database characterset.
check NLS parameters
Please also advice me how to change db charset, pre-requesits and its steps.
Refer
http://download.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm
http://www.oracle-base.com/articles/10g/CharacterSetMigration.php
http://www.oracle.com/technology/tech/globalization/pdf/TWP_Character_Set_Migration_Best_Practices_10gR2.pdf
- Pavan Kumar N

Similar Messages

  • Characterset Problem after migrating to new database

    Hi, I'm developing a application on local system with these settings
    NLS_CHARACTERSET:     WE8MSWIN1252
    DAD CHARACTERSET: UTF-8
    and then we moved it to our server with these settings
    NLS_CHARACTERSET:     WE8MSWIN1252
    DAD CHARACTERSET:     
    after that we are having character set problem, some characters are not displayed correctly. Not just in application but also the data in the database.
    (a result from a query which been done with sql commands from apex)
    http://img340.imageshack.us/img340/9123/charsetprob.jpg
    But the characters are displayed correctly on csv export.
    On the application itself, sometimes its always displayed correctly for the first time the page was rendered, after a partial refresh or paging the same problem occurs.
    1st time rendered
    http://img690.imageshack.us/img690/2310/charsetprob2.jpg
    after paging
    http://img690.imageshack.us/img690/3784/charsetprob3.jpg
    is it because DAD Characterset was not set on our server?
    can someone please enlight me, I would be very thankful for your help.
    Danny

    Sorry but I still has not resolve this problem yet. Can someone help me?
    edit: case solved
    Edited by: raitodn on 30.06.2010 07:16

  • UTF8 characterset problem

    I have a database that has been installed with the UTF8 characterset.
    Therefore the £ sign is ASCII 49827 in this characterset and not ASCII 163 as used in ISO8859P1. I believe my problem stems from me using UTF complaint clients to enter the £ sign into the database. Because the Clients are UTF8 compaint they are passing ASCII 49827 for the £ sign into the database. However when non UTF8 compliants try to view or manipulate the data from this database, instead of them seeing the £ sign they see £.
    I presume the solution should be to ensure all viewing clients are UTF8 compliant ?
    My problem is that I have a 3rd party program that is taking the output from the database in the form of a text file and is then converting the output into a PDF. Hence in the PDF the £ sign is appearing as £, since this is what is effectively stored in the database / text file output
    I presume it never makes sense to try and convert the Database using CSALTER to WE8ISO8859P1 from UTF8 ? ( as WE8ISO8859P1 is a sub set of UTF8 ? )
    The routine that is creating the test file from the database is an E-Business Suite routine, so I cannot interfer with it and put in a translate command.
    Any suggestions ?
    thanks,
    Jim

    what is NLS_CHARACTERSET value of your database?
    I always use AR8MISO8859P6 and it's perfect for Arabic language.
    For your Application Server, in the registry, check
    NLS_LANG = AMERICAN_AMERICA.AR8MSWIN1256
    REPORT_ARABIC_NUMERAL = ARABIC
    REPORTS_PATH = (Make sure your font path is included here)
    Add these entries in your uifont.ali file under [ PDF:Subset]
    [ PDF:Subset ]
    Arial..Italic.Bold.. = "Arialbi.ttf"
    Arial..Italic... = "Ariali.ttf"
    Arial...Bold.. = "Arialbd.ttf"
    Arial..... = "Arial.ttf"
    "Arabic Transparent"..Italic.Bold.. = "ARIALBI.TTF".....
    "Arabic Transparent"..Italic... = "ARIALI.TTF".....
    "Arabic Transparent"...Bold.. = "Arialbd.ttf"
    "Arabic Transparent"..... = "artro.ttf"
    Tahoma = "tahoma.ttf".....ar8mswin1256
    Arial = "Tahoma"
    "Tahoma Bold" = "tahomabd.ttf"
    Make sure Regional and Language option in control panel is properly configured for Arabic.
    restart the Windows Server 2003 and arabic should work properly on Server 2003 also.
    I'm using Oracle Application Server 10g on Windows 2003 Server and Arabic Language is working perfectly for forms as well as PDF Reports.
    I'm using Tahoma font for Arabic.
    Hope this will help and solve your problem.
    Note: Make sure that the font which you are using for Arabic in your reports is included in the uifont.ali
    regards,
    Saadat Ahmad
    Message was edited by:
    saadatahmad

  • Arabic_lang characterset problem with Toad

    Hi there
    I have install oracle10g DB and Developer
    and also i install Toad 8.0 but i have problem the Arabic character its not showing in Toad but with the form and DB its ok i can read Arabic characters....
    anyone can help me in this?
    thanx in advance...

    What did you choose for character sets when creating the database?
    Please note that otn has a forum dedicated to discussion realted to Globalization Support features (language and character sets, etc.).

  • AL32UTF8 characterset  problem

    Hi
    I have a db called  DB1 which have
    select * from v$nls_parameters;
    PARAMETER     VALUE
    NLS_LANGUAGE     AMERICAN
    NLS_TERRITORY     AMERICA
    NLS_CURRENCY     $
    NLS_ISO_CURRENCY     AMERICA
    NLS_NUMERIC_CHARACTERS     .,
    NLS_CALENDAR     GREGORIAN
    NLS_DATE_FORMAT     DD-MON-YY
    NLS_DATE_LANGUAGE     AMERICAN
    NLS_CHARACTERSET     WE8ISO8859P1
    NLS_SORT     BINARY
    NLS_TIME_FORMAT     HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT     DD-MON-YY HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZH:TZM
    NLS_TIMESTAMP_TZ_FORMAT     DD-MON-YY HH.MI.SSXFF AM TZH:TZM
    NLS_DUAL_CURRENCY     $
    NLS_NCHAR_CHARACTERSET     WE8ISO8859P1
    NLS_COMP     BINARY
    select chr(200) from dual ; give -> È
    i had another db DB2
    select * from v$nls_parameters;
    NLS_LANGUAGE     ENGLISH
    NLS_TERRITORY     AUSTRALIA
    NLS_CURRENCY     $
    NLS_ISO_CURRENCY     AUSTRALIA
    NLS_NUMERIC_CHARACTERS     .,
    NLS_CALENDAR     GREGORIAN
    NLS_DATE_FORMAT     DD/MON/RR
    NLS_DATE_LANGUAGE     ENGLISH
    NLS_CHARACTERSET     AL32UTF8
    NLS_SORT     BINARY
    NLS_TIME_FORMAT     HH12:MI:SSXFF AM
    NLS_TIMESTAMP_FORMAT     DD/MON/RR HH12:MI:SSXFF AM
    NLS_TIME_TZ_FORMAT     HH12:MI:SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT     DD/MON/RR HH12:MI:SSXFF AM TZR
    NLS_DUAL_CURRENCY     $
    NLS_NCHAR_CHARACTERSET     AL16UTF16
    NLS_COMP     BINARY
    NLS_LENGTH_SEMANTICS     BYTE
    NLS_NCHAR_CONV_EXCP     FALSE
    select chr(200) from dual ; give -> NULL !!!
    please help me fix DB2 problem?
    Thanks

    I am assuming you would like to change the character set of DB2 to match that of DB1. If your database is 9i or greater you might want to take a look at the docs on character set migration.
    http://download.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1656

  • Calendar sync characterset problem

    Hi,
    when I synchronize with sony clié Pocket (PALM OS 5), the accentuated characters are changed : ex: "Comité" on outlook becomes "Comité" on Palm and "Allée" on Palm becomes "All¿" on outlook.
    How can I resolve this problem
    Thanks

    Hi,
    Can you tell me what version of the Calendar Sync for Palm you are running? Also, what version of Outlook, as well as the version of the Connector for Outlook, and the Palm desktop you have.
    Thanks,
    Lily

  • Problem with Arabic characters

    Hi:
    I don't know if this is the correct place to post the question, but here it goes...
    I have an SQL 2005 database, connected via a Linked Server to an Oracle Database.
    I have a table in SQL that contains arabic characters, and I need to insert it into an Oracle table.
    These characters appear as "????" after being inserted in the oracle table.
    I guess I hace some collation/characterset problem, but cannot finf the solution.
    The column where the arabic characyers are saved in SQL is defined as:
         [Remarks] [nvarchar](1000) NULL,
    And default SQL server collation is: SQL_Latin1_General_CP1_CI_AS
    When I do a select on this table, it can see arabic correctly.
    ORACLE NLS CONFIGURATION IS:
    PARAMETER VALUE
    NLS_LANGUAGE AMERICAN
    NLS_TERRITORY AMERICA
    NLS_CURRENCY $
    NLS_ISO_CURRENCY AMERICA
    NLS_NUMERIC_CHARACTERS .,
    NLS_CHARACTERSET AR8MSWIN1256
    NLS_CALENDAR GREGORIAN
    NLS_DATE_FORMAT DD-MON-RR
    NLS_DATE_LANGUAGE AMERICAN
    NLS_SORT BINARY
    NLS_TIME_FORMAT HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY $
    NLS_COMP BINARY
    NLS_LENGTH_SEMANTICS BYTE
    NLS_NCHAR_CONV_EXCP FALSE
    NLS_NCHAR_CHARACTERSET AL16UTF16
    NLS_RDBMS_VERSION 11.1.0.6.0
    The sql sentence in SQL server that moves the data to oracle is:
    INSERT INTO openquery(Oracle_DB, 'select Ticket_NO,Remarks from webportal.webcc_escal_det')
         (Ticket_NO,Remarks )
         SELECT Ticket_NO, Remarks
         FROM Details(nolock)
    Thanks in advance!!
    Mariana

    I think first you should check your character set
    SELECT * FROM NLS_DATABASE_PARAMETERS where parameter = 'NLS_CHARACTERSET'
    For oracle to display correctly, you need to change your character set that caters to Arabic

  • Webutil_File_Transfer.DB_To_Client with different result

    hi
    Forms 10.1.2.3
    i use in Forms this function to Downlaod BLOBs
    Webutil_File_Transfer.DB_To_Client
         ('H:\l.xml',
         'T_DEV_ARCHIV',
         'dar_xml_blob',
         'dar_id=110874')
    In the BLOB are German letters inside ü, ä, ö ..
    Result on two Clients:
    at the first client the result looks good
    On the other Client I’m missing the German letters.
    Why the transfer is different? What has to do with the client?
    BLOB's are binary files !!!
    I just despair.
    Edited by: alinzenb on 04.03.2013 13:16

    Yes, but did you add a characterset definition to your XML file, and does the data stored in the XML match this characterset?
    If you have e.g.
    <?xml version="1.0" encoding="windows-1252" ?>But the data in the blob is actually UTF-8 encoded you have a Characterset-Problem, as the XML parser will treat your (UTF-8 data) as windows-1252 data...
    cheers

  • Can RMAN restore TS with different name?

    Hi all,
    I have the RMAN TS backup (let's say 'HR') and am trying to restore it in the same database into different TS (let's say HR_TEST). However, I could use expdp (datapump) method, but since I have RMAN TS backup running daily, and would like to take advantage of it. Any idea would greatly appreciated. By the way, I am running on 10.2.0.1 Sun Solaris. Thanks again.

    Yes,
    I tried to export process. However, I ran into characterset problem and the error was
    Export done in US7ASCII character set and AL16UTLF16NCHAR character set
    Server uses WE8MSWIN1252 character set (possible charset conversion)
    EXP-0056:ORACLE error 932 encountered
    ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
    I also set my global environment NLS_CHARACTERSET to WE8MSWIN1252, but did not work. Do you have any idea I should set my character set? Or maybe I should check into transport TS method? Thank you very much.

  • Problem in JMS-Adapter with CharacterSet Websphere MQ

    Hi,
    we have the following scenario:
    JMS -> PI -> File
    We have a local Websphere MQ Queue Manager and the follwoing configuration in our sender adapter:
    Transport-Protocol: WebSphere MQ (non JMS)
    Message-Protocol: JMS 1.x
    ConnectionFactory: com.ibm.mq.jms.MQQueueConnectionFactory
    Java-class Queue: com.ibm.mq.jms.MQQueue
    CCSID: 819
    Transport: TCP/IP
    JMS-conform: WebSphere MQ (non JMS)
    In the local queue manager the messages (XML-Messages with header <?xml version="1.0" encoding="ISO-8859-1"?>) have characterSet 819 (ISO-8859-1). That's correct. You can open the files with XMLSpy and it works.
    When we receive the messages by our JMS Sender Adapter all the character seems to be in UTF-8 and I don't know why. All the special characters are wrong cause the header of the XML-message shows ISO-8859-1 but all the signs are decoded in UTF-8.
    In the other direction (JMS Receiver adapter, File -> PI - JMS) we have the same problem.
    We create a ISO-8859-1 message in mapping (and it is really ISO-8859-1) and send it via JMS Receiver Adapter to the local message queue. But there the message arrives in UTF-8 encoding. I don't understand this.
    Does anybody know what could be the cause for this?
    Does the JMS adapter convert the messages from ISO-8859-1 into UTF-8?
    Are there any parameters we have to set?
    I hope anybody has an idea what's wrong.
    Regards
    Thorsten
    Edited by: Thorsten Hautz on Oct 12, 2010 5:42 PM

    Hi,
    thanks a lot for your replies.
    our driver settings are correct (as I can see).
    I removed value 819 from CCSID, but we have the same effect.
    The messages in the local queue manager are TextMessages in XML.
    Does anybody know, if we need the standard modules (ConvertJMSMessageToBinary and ConvertBinaryToXMBMessage) in this case?
    Is it possible to set the CCSID for the message payload anywhere in the configuration?
    The CCSID in the Source tab doesn't have any influence to the encoding of the payload message, only to the header data.
    Regards
    Thorsten

  • Problem with the Characterset

    We are facing a problem with using the characterset.
    The database characterset is WE8ISO8859P1. In one of the modules
    we need to store some multi-lingual data which also includes
    some chineses and japanese characters.
    So, we tried to change the client(running on windows 98 and db
    server running on a Sun box) NLS_LANG to French_France.UTF8 in
    the registry. Then when we issued the query,
    select userenv('language') from dual;
    French_France.WE8ISO8859P1
    was the output.
    Is it possible to set the client's characterset different from
    the server's character set?

    First, USERENV('language') returns the Language and Territory of
    your user session and the character set of your database (not
    your user session). So, the output from USERENV('language') is
    not your user session character set.
    Second, whether or not you can change your user session
    character set depends on whether or not your client application
    or client terminal supports that character set. By default,
    your user session will use the character set of your terminal.
    If you need, you can change it to the character set of your
    client application (Windows 98 for your case). So, you can
    change the character set to UTF8 only when your platform support
    UTF8.

  • Problem finding docs using content index in DB with different charactersets

    Sorry for duplicating thread from [url http://forums.oracle.com/forums/thread.jspa?threadID=653067&tstart=0]this thread in Oracle Text forum, but it seems quite slow compared to this one, so probably someone has some suggestion.
    Problem explanation:
    DB version 10.2.0.1 SE on windows
    database characterset AL32UTF8
    I am creating following context index:
    create index myindex on g(Content)
    indextype is ctxsys.context
      parameters('filter ctxsys.auto_filter
      section group ctxsys.null_SECTION_GROUP');With following query:
    SELECT distinct filename FROM g f
    WHERE contains(F.Content, 'latiinju') >0;I can find latin symbols in ansi, utf-8 encoded text documents and msword and msexcel documents.
    With following query:
    SELECT distinct filename FROM g f
    WHERE contains(F.Content, 'latviešu') >0;I can find latvian symbols in utf-8 encoded text documents and msword and msexcel documents, which basically is OK.
    However there is another unfortunately already production database
    10.2.0.3.0 SE on windows
    with characterset BLT8CP921
    and with index as defined above queries find absolutely nothing for both latin and latvian texts.
    As soon as I've added another column "cset" in the table and filled it up with AL32UTF8 I can find latin characters for the same cases as in db above.
    Index in this case is as follows:
    create index myindex on g(Content)
    indextype is ctxsys.context
      parameters('filter ctxsys.auto_filter
      section group ctxsys.null_SECTION_GROUP
      charset column cset');However the problem is that for latvian characters it can find only UTF-8 encoded text files, but not doc and xls files and that's absolutely not OK.
    I've tried also another charactersets in cset columns, but without any success.
    So the question is - is there any possibility somehow to create the content index that it is possible to find also latvian specific symbols in doc and xls files in DB with characterset BLT8CP921?
    Of course the ultimate solution would be to recreate db with AL32UTF8 characterset but I'd like to avoid that if possible.
    TIA
    Gints Plivna

    I have applied performance tuning steps, like JAVA_POOL_SIZE, SGA_MAX_SIZE, increase table spaces size and change some other DB parameters. After applied, problematic index has been created without error and application is running fine without any error. Many thanks for your prompt suggestion, by which I could narrow down my problem. So, as my problem has been resolved, so please close this thread.
    Regards,
    Farhan Mazhar

  • {SOL}Problem in Export/Import a simple table between two diff. characterset

    Hi ,
    I have created a simple table on SCOTT schema....
    SQL> CREATE TABLE TEST(A NUMBER(1) , B VARCHAR2(10));
    Table created
    SQL> INSERT INTO TEST VALUES(1 , 'TEST_TEST');
    1 row inserted
    SQL> COMMIT;
    Commit complete
    SQL> INSERT INTO TEST VALUES(2 , 'ΤΕΣΤ_ΤΕΣΤ');     <------------greek chars
    1 row inserted
    SQL> COMMIT;
    Commit complete
    The nls_parameters:
    SQL> SELECT * FROM NLS_INSTANCE_PARAMETERS;
    PARAMETER                      VALUE
    NLS_LANGUAGE                   GREEK
    NLS_TERRITORY                  GREECE
    NLS_SORT                      
    NLS_DATE_LANGUAGE             
    NLS_DATE_FORMAT               
    NLS_CURRENCY                  
    NLS_NUMERIC_CHARACTERS        
    NLS_ISO_CURRENCY              
    NLS_CALENDAR                  
    NLS_TIME_FORMAT               
    NLS_TIMESTAMP_FORMAT          
    NLS_TIME_TZ_FORMAT            
    NLS_TIMESTAMP_TZ_FORMAT       
    NLS_DUAL_CURRENCY             
    NLS_COMP                      
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    17 rows selected
    SQL> SELECT * FROM NLS_SESSION_PARAMETERS;
    PARAMETER                      VALUE
    NLS_LANGUAGE                   AMERICAN
    NLS_TERRITORY                  AMERICA
    NLS_CURRENCY                   $
    NLS_ISO_CURRENCY               AMERICA
    NLS_NUMERIC_CHARACTERS         .,
    NLS_CALENDAR                   GREGORIAN
    NLS_DATE_FORMAT                DD-MON-RR
    NLS_DATE_LANGUAGE              AMERICAN
    NLS_SORT                       BINARY
    NLS_TIME_FORMAT                HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY              $
    NLS_COMP                       BINARY
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    17 rows selected
    and db characterset is EL8MSWIN1253
    I export such as(following generally the instuctions found on Note:227332.1-Metalink):
    C:\Documents and Settings\s_k>SET ORACLE_SID=EPESY
    C:\Documents and Settings\s_k>SET NLS_LANG=GREEK_GREECE.EL8MSWIN1253
    C:\Documents and Settings\s_k>C:\oracle\product\10.2.0\database10g\BIN\exp SYSTE
    M/passwd@EPESY FILE=C:\TEST.DMP TABLES=(SCOTT.TEST) ROWS=Y LOG=C:\TEST2.TXT
    Export: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:28:58 2008
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    ╕ήώΊί ≤²Ίϊί≤ύ ≤ί: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Pr
    oduction
    With the Partitioning, OLAP and Data Mining options
    ╟ ίΌάή∙ή▐ ▌ήώΊί ≤ΪΎ ≤ίΪ ≈ά±άΆΪ▐±∙Ί EL8MSWIN1253 Άάώ ≤ΪΎ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR AL1
    6UTF16
    ╨±ΎίΪΎώΉά≤▀ά ήώά ίΌάή∙ή▐ Ϊ∙Ί Ώ±Ύ≤ϊώΎ±ώ≤Ή▌Ί∙Ί ΏώΊ▄Ά∙Ί Ή▌≤∙ ╙ΫΉέάΪώΆ▐≥ ─ώάϊ±ΎΉ▐≥ .
    ╧ Ϊ±▌≈∙Ί ≈±▐≤Ϊύ≥ ▄ΈΈάΌί ≤ί SCOTT
    . . ίΌάή∙ή▐ ΪΎΫ Ώ▀ΊάΆά                           TEST          2 ή±άΉΉ▌≥ ίΌ▐≈ϋύ≤
    άΊ
    ╟ ίΌάή∙ή▐ ΪίΈί▀∙≤ί ίΏώΪΫ≈■≥ ≈∙±▀≥ Ώ±ΎίώϊΎΏΎ▀ύ≤ύ.Then , i shutdown this database and i start the other.....
    with this nls_parameters
    SQL> select * from nls_session_parameters;
    PARAMETER                                                                        VALUE
    NLS_LANGUAGE                                                                     AMERICAN
    NLS_TERRITORY                                                                    AMERICA
    NLS_CURRENCY                                                                     $
    NLS_ISO_CURRENCY                                                                 AMERICA
    NLS_NUMERIC_CHARACTERS                                                           .,
    NLS_CALENDAR                                                                     GREGORIAN
    NLS_DATE_FORMAT                                                                  DD-MON-RR
    NLS_DATE_LANGUAGE                                                                AMERICAN
    NLS_SORT                                                                         BINARY
    NLS_TIME_FORMAT                                                                  HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT                                                             DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT                                                               HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT                                                          DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY                                                                $
    NLS_COMP                                                                         BINARY
    NLS_LENGTH_SEMANTICS                                                             CHAR
    NLS_NCHAR_CONV_EXCP                                                              FALSE
    17 rows selected
    SQL>
    SQL> select * from nls_instance_parameters;
    PARAMETER                                                                        VALUE
    NLS_LANGUAGE                                                                     GREEK
    NLS_TERRITORY                                                                    GREECE
    NLS_SORT                                                                        
    NLS_DATE_LANGUAGE                                                               
    NLS_DATE_FORMAT                                                                 
    NLS_CURRENCY                                                                    
    NLS_NUMERIC_CHARACTERS                                                          
    NLS_ISO_CURRENCY                                                                
    NLS_CALENDAR                                                                    
    NLS_TIME_FORMAT                                                                 
    NLS_TIMESTAMP_FORMAT                                                            
    NLS_TIME_TZ_FORMAT                                                              
    NLS_TIMESTAMP_TZ_FORMAT                                                         
    NLS_DUAL_CURRENCY                                                               
    NLS_COMP                                                                        
    NLS_LENGTH_SEMANTICS                                                             CHAR
    NLS_NCHAR_CONV_EXCP                                                              FALSE
    17 rows selected
    with this db characterset: UTF8
    C:\Documents and Settings\s_k>SET NLS_LANG=GREEK_GREECE.EL8MSWIN1253
    C:\Documents and Settings\s_k>C:\oracle\product\10.2.0\database10g\BIN\imp syste
    m/passwd@info FROMUSER=SCOTT TOUSER=SCOTT FILE=C:\TEST.DMP LOG=C:\TEST0_IMP.TXT
    Import: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:40:16 2008
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    ╕ήώΊί ≤²Ίϊί≤ύ ≤ί: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Pr
    oduction
    With the Partitioning, OLAP and Data Mining options
    ┴±≈ί▀Ύ ίΌάή∙ή▐≥ ϊύΉώΎΫ±ή▐ϋύΆί άΏⁿ EXPORT:V10.02.01 Ή▌≤∙ ≤ΫΉέάΪώΆ▐≥ ϊώάϊ±ΎΉ▐≥
    ίώ≤άή∙ή▐ ▌ήώΊί ≤ί ≤ίΪ ≈ά±άΆΪ▐±∙Ί EL8MSWIN1253 Άάώ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR UTF8
    server ίώ≤άή∙ή▐≥ ≈±ύ≤ώΉΎΏΎώί▀ ≤ίΪ ≈ά±άΆΪ▐±∙Ί UTF8 (ϊΫΊάΪ▐ ΉίΪάΪ±ΎΏ▐ ≤ίΪ ≈ά±άΆΪ▐±
    ∙Ί)
    server ίΌάή∙ή▐≥ ≈±ύ≤ώΉΎΏΎώί▀ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR AL16UTF16 (ϊΫΊάΪ▐ ΉίΪάΪ±ΎΏ▐ ≤ί
    Ϊ ≈ά±άΆΪ▐±∙Ί nchar)
    . ίώ≤άή∙ή▐ Ϊ∙Ί άΊΪώΆίώΉ▌Ί∙Ί ΪΎΫ SCOTT ≤ΪΎ SCOTT
    . . ίώ≤άή∙ή▐ ΪΎΫ Ώ▀ΊάΆά                         "TEST"          2 ή±άΉΉ▌≥ ίώ≤▐≈ϋ
    ύ≤άΊ
    ╟ ίώ≤άή∙ή▐ ΪίΈί▀∙≤ί ίΏώΪΫ≈■≥ ≈∙±▀≥ Ώ±ΎίώϊΎΏΎ▀ύ≤ύ.
    C:\Documents and Settings\s_k>SQLPLUS SCOTT/TIGER
    SQL*Plus: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:41:20 2008
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    ╙²Ίϊί≤ύ ≤ί:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    SQL> SELECT * FROM TEST;
             A B
             1 TEST_TEST
             2 ????_????What may be the cause.....????
    Note: I use db 10g v.2 on Windows XP platform.. and the two db instances reside on the same machine....
    Thanks...
    Sim

    "Generally speaking the value of the NLS_LANG registry key or environment variable needs to be equal to the characterset of the database."
    Yes...that's why i have set the NLS_LANG env.variable to GREEK_GREECE.EL8MSWIN1253 ..equal to:
    SQL> select * from nls_database_parameters;
    PARAMETER                      VALUE
    NLS_LANGUAGE                   AMERICAN
    NLS_TERRITORY                  AMERICA
    NLS_CURRENCY                   $
    NLS_ISO_CURRENCY               AMERICA
    NLS_NUMERIC_CHARACTERS         .,
    NLS_CHARACTERSET EL8MSWIN1253
    NLS_CALENDAR                   GREGORIAN
    NLS_DATE_FORMAT                DD-MON-RR
    NLS_DATE_LANGUAGE              AMERICAN
    NLS_SORT                       BINARY
    NLS_TIME_FORMAT                HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY              $
    NLS_COMP                       BINARY
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    NLS_NCHAR_CHARACTERSET         AL16UTF16
    NLS_RDBMS_VERSION              10.2.0.1.0"nls_language doesn't come into play, nor nls_instance_parameters."
    Yes...it's true.
    "So, in the dump you posted, no one can tell whether those characters were INSERTed correctly at all. Your NLS_LANG *registry key* may have been set to an incorrect value (it defaults to American_America.MSWIN1252)."
    Actually , i have used a third-party tool PL/SQL Developer (which does have the OracleDB10g as default home).
    Looking at the Windows registry of OracleDB10g the NLS_LANG is equal to GREEK_GREECE.EL8MSWIN1253.
    "Thirdly, as I implied above the NLS_LANG on import should have been American_America.UTF8."
    According to the Note 227332.1 , if the db characterset of the two dbs are not the same.. then it is preferable the conversion should be done on the import process and not the export....
    So, in an example described there -export from a AMERICAN_AMERICA.WE8MSWIN1252 db and import on UTF8 db - (seems exactly the same as mine) the import is done as such:
    c:\>set NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
           c:\>imp ....
    The conversion to UTF8 is done while inserting the data
           in the UTF8 database.Additional notes....
    I have used many different patterns doing the import......
    1) Use of AMERICAN_AMERICA.UTF8
    2) Use of GREEK_GREECE.EL8ISO8859P7
    3) Use the appropriate NLS_LANG that corresponds to the display of chcp command....
    All tries display some '?' chars.....
    Anyway... I 'll continue reading ... and testing
    Thanks... a lot for your points
    Sim

  • Some problems about oracle.sql.CharacterSet.java

    When I debugging a program,which should execute an insert statement into Oracle database,but I found there's missing Oracle.sql.CharacterSet.java source file&#65292;and some errors occur&#65306;
    java.sql.SQLException: ORA-01400: cannot insert NULL into ("EPICS"."IOC_DB_FILE_ASGN"."EXT_SRC_FILE_NM")
    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:124)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:304)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:271)
    at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:622)
    at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:180)
    at oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:542)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1027)
    at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2887)
    at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:2978)
    at gov.sns.apps.jeri.apps.dbimport.DBFileParser.updateDBFileIOCData(DBFileParser.java:3028)
    at gov.sns.apps.jeri.apps.dbimport.DBFileParser.saveToDatabase(DBFileParser.java:2930)
    at gov.sns.apps.jeri.apps.dbimport.DBImportFrame$19.run(DBImportFrame.java:640)
    at java.lang.Thread.run(Thread.java:534)
    The database is Oracle 10g&#65292;and development tools is Jdeveloper10g&#12290;I have added oracle_home/jdbc/lib/classes12.jar into the classpath.but it doesn't work&#12290;I hope someone can tell me what's the matter and how to get the source file of CharacterSet.java&#65311;I'll be very grateful for your help!Thank you very much!

    hello user457523
    I have found the reason to that error.It's because there's a trigger and ext_src_file_nm is populated by the trigger from another column ext_src_file_loc when inserting and I didn't give any value to ext_src_file_loc so ext_src_file_nm is null.
    I have disabled that trigger and now I get new errors.When I traced to a line of Jave code I got missing source file warning,and the source file is also oracle.sql.CharacterSet.java.I can not trace into the source file and then I skipped that code and then I got new errors.I want to know how to trace into the jave code and find what's the matter.
    Thank you very much.

  • Problem: Materialized View between Oracle servers w/different CHARACTERSET

    I am trying to create a MATERIALIZED VIEW where the master table is a remote Oracle 8 server with NLS_CHARACTERSET = 'WE8ISO8859P1'. The destination view is an Oracle 10g with NLS_CHARACTERSET = 'AL32UTF8'.
    I am getting error: ORA-12703: this character set conversion is not supported.
    I've tried to use CONVERT on my SELECT statment but according to the error message, CONVERT does not support 'AL32UTF8'.
    I need help. Please!

    First off, I'd strongly suggest reading through Metalink Note 237593.1 Problems connecting to AL32UTF8 databases from older versions (8i and lower).
    There is a good chance that the destination database character set will need to be converted to UTF8 rather than AL32UTF8 (assuming that this isn't going to cause issues with surrogate pairs). You may be able to keep the destination character set unchanged if you install at least the 8.1.7.4 patchset on the source database as well as a hanfddful of different one-off patches, but it looks like you're probably going to need to change the destination character set.
    Justin

Maybe you are looking for