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

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

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

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.).

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 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

Using AL32UTF8 or ZHS16GBK Characterset

Hi,
Currently, our database is using AL32UTF8 as the characterset but we need to store some Simplified Chinese data in tables.
I know what AL32UTF8 characterset is able to store Simplified Chinese data but not being able to sort the Chinese character by Han yu pin yin (By default). The default is by Binary.
I also know that ZHS16GBK characterset is able to store Simplified Chinese and the default sorting is by Han yu pin yin, which is what I want.
1. So I just wonder what type of characterset should I use, AL32UTF8 or ZHS16GBK?
2. AL32UTF8 is an unicode characterset which can support multi-language but ZHS16GBK characterset can only store Simplified Chinese? Am I right? What about English words, can ZHS16GBK characterset being able to store English words?
3.Which is the recommended Characterset to use for my case?
4. If I choose to set my characterset as AL32UTF8 but I want all the Simplified Chinese data to be sort by Han yu pin yin, how should I do?
5. I read one of the documentation and it state that I can set the NLS_SORT in the nls_Session_parameters to SCHINESE_PINYIN_M. After setting the session parameters, I want into SQLPLUS and execute a select statement (e.g. select short_name from client order by short_name) and the Simplified Chinese short name retrieve is sorted by Han yu pin yin. But when my application (NOT through SQLPLUS) execute the same select statement, the result is not sorted by Han yu pin yin. Why is this so? Did I miss out anything?
6. Lastly, I tried to set the NLS_SORT in the instance parameters as well by changing the spfile but the application using the select statement still cannot sort the Simplified Chinese data by Han yu pin yin. What should I do?

Hi,
Actually, I change the nls_sort for the session paramaters through the setting of the nls_sort in the registry instead of using the alter session command line.
This is so as using alter session command line will only change the nls_sort for that particular session and once I exit the session, the nls_sort will be reset back to the default which is in Binary. I will have to re-alter the nls_sort in the session parameters again.
Thats why I set the nls_sort in the registry so that the nls_sort in the session parameters will remain in the client machine.
After setting the nls_sort in the registry, I am able to sort the Simplified Chinese characters by Han yu pin yin using the SQL*PLUS but not in my application.
My applications are running on Windows environment (Microsoft Windows 2000 5.00.2195 SP3).
The applications are split into front-end and back-end. The backend is using java and the front-end is using a software that is also using java to control.
Basically, the front-end application will execute an electronic data exchange service and it will establish a jdbc oracle thin connection to the database.
There is configuration file that is attached with each Electronic data exchange service. This configuration file contains the select statement (select short_name from client order by short_name) and each configuration file is linked with a datasource which will establish a jdbc oracle thin connection to the database.
But seems like the result of the select statement in the configuration file are not sorted by Han yu pin yin. But executing the same select statement through SQL*PLUS will return the data sorted by Han yu pin yin.
Thanks.

Migration Characterset Issue

Hi,
I am involved in a Data Migration project.
The database version I am using is Oracle 10.2.0.5 and the NLS_CHARACTERSET is set to UTF8 on the database.
The requirement is to provide the data extract in Unicode for the new databse.
I have set the NLS_LANG variable to AL32UTF8 on my machine.
For extracting the data from all the tables except one, I did not face any problems.
But for one table,while exporting the data I got the error ORA:29275 and ORA-12703 while trying to convert the strings.
I was able to address this issue by changing the characterset on my machine to UTF8.
My Question is:
1)Will the extract files pulled out in AL32UTF8 characterset pose a problem to the new database(if in UTF8) where the data has to be migrated?
2)I got to know that Oracle UTF8 is not exactly "Unicode" as per the standards, so how do I address the dataset in UTF8 if to be provided in Unicode?
thanks in advance
deb

It would seem this post should have been posted in {forum:id=50}.
1. How exactly are you "extracting the data"?
In general, when using export tool, you should use a client char set that matches the database, as to avoid or delay conversion.
(Oracle character sets UTF8 and AL32UTF8 are not the same.)
But ORA-29275 possibly indicates some problem with source data, so it is best to investigate the issue.
Why does the new database have UTF8 over the current AL32UTF8? The first, UTF8 should be used only when (the very old) client applications require it.
2. Where did you read this?
See Globalization Support guide about Unicode versions and Oracle character sets.

Change characterset to WE8MSWIN1252

When I try to change characterset from AL32UTF8 to WE8MSWIN1252, I get this error:-
ORA-12712: new character set must be a superset of old character set.
a) How to switch off the superset check to allow changes between formally incompatible character sets to solve this character set problem ?
b) Or is it that there is only one way to solve this problem :-
1) export database
2) reinstall database
3) Import database
c) Can some one tell me that ø,æ,å characters are found in AL32UTF8 characterset.
Rajkum

I had read somewhere that simply using the command to change the characterset does not quite do a clean job. The best way is to recreate the db.

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

How varchar is stored in AL32UTF8 code page

I have a basic question.
from the technical documentation we can allocate length VARCHAR2 in bytes or char.
i wnat to know in if i use AL32UTF8 characterset and if i allocate lenght of a column as VARCHAR2(1 CHAR) then how many bites does this take if i store a lette 'A'.
Thanks,
Sakthi

You can answer that question yourself, can't you?
Please use the DUMP function or VSIZE.
Please,PLEASE, PLEASE, TRY TO DO ANY EFFORT YOURSELF!!!!!!!!!!!!!!!!!!!!!!!!!!!
YOU DON"T NEED THIS FORUM.
MOST PEOPLE 'NEED' THIS FORUM, BECAUSE THEY KNOW NOTHING, AND ARE FUNDAMENTALLY LAZY!!!
Sybrand Bakker
Senior Oracle DBA
Experts: those who *did* read documentation.

Oracle Forms 6i(32-bit) = Oracle database 10g R2 Windows 2008 R2 64-bit)

We have Oracle database 10g R2 installed on a Microsoft Windows 2008 R2 (64-bit) (SERVER1)
We have Oracle Forms 6i (patch 4a) installed on a Microsoft Windows XP Professional (32-bit) (SERVER2)
I am not able to connect from SERVER2 to SERVER1, either through SQLPLUS or FORMS BUILDER.
Its giving some DLL error.
Is it because forms 6i (32-bit) cannot connect to a 64-bit database on a 64-bit OS ?

There might be problems with 8i clients (like forms 6i) if the database uses AL32UTF8 characterset indeed (if you need unicode and you need to run forms 6i use UTF8 instead) but this should not be related to the platform of the database.
The platform of the database server really should not matter as the forms runtime talks via SQL*Net with the database server and in the end it does not matter if the database runs on linux, windows whatsoever or unix 32 or 64 bit for the client. The only problem you'll encounter is that SQL*Net also changes with versions and thus "older" clients might not be able to communicate with "newer" servers and vice versa.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for 64-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> select * from v$nls_parameters where parameter = 'NLS_CHARACTERSET';
PARAMETER                                                       |VALUE
----------------------------------------------------------------|---------------------------
NLS_CHARACTERSET                                                |WE8MSWIN1252
SQL>I just tried a 6i form (6.0.8.25.2) connected to this database. It worked ;) (again: not certified)
cheers

Arabic Characters Issue

Hi
Following is our environment
DB Version: Oracle 11g R2 (11.2.0.3.0) 64bit
OS : OEL 5U2
Characterset: AMERICAN_AMERICA.AR8MSWIN1256
We have an opensource application built on php. CHARSET was defined as AR8MSWIN1256 in the configuration file. Data was inserted using browser based interface. Use access the system using IE 8 since it is web based application. Data comprise of both Arabic and English. It is displayed perfectly fine using browser ie Arabic shows proper Arabic characters and English shows correct English.
Problem started when a requirement came to generate some reports using Oracle Reports 10g. Arabic data show as garbage in the reports. Vendor was asked to provide some solution. They suggested to change the CHARSET to AL32UTF8 in the config file of the application. After making the changes, the new data that is inserted in the database can be seen correctly for both languages regardless of the tool (be it SQLDeveloper or Oracle Reports). The old data, however, shows garbage. Surprisingly when data is extracted using scripts in flat files and then imported in the test database after setting environment variable NLS_LANG=AMERICAN_AMERICA.UTF8 using @/../filename.sql, it converts it properly. Since data is huge and this is taking way too much time, I was hoping if someone could help me in quickly perform this migration? Already tried CSSCAN/CSALTER and DMU but did not succeed. DMU stopped at 5th stage when it was supposed to issue ALTER DATABASE CHARACTER SET command.
Currently I am installing database with AL32UTF8 characterset and planning to import the schema in it. Is my approach correct? Any help will be highly appreciated.
Thank you
myuser@DB>select dump(name,1016) from mytable where id like '1';
DUMP(NAME,1016)
Typ=1 Len=28 CharacterSet=AR8MSWIN1256: d9,81,d8,b1,d9,8a,d9,82,20,d8,b9,d9,85,d9,84,20,d8,a7,d9,84,d9,82,d8,b7,d8,a7,d8,b9
myuser@DB>select dump(name,1016) from mytable where id like '2';
DUMP(NAME,1016)
Typ=1 Len=93 CharacterSet=AR8MSWIN1256: d8,aa,d8,b9,d8,a7,d9,85,d9,8a,d9,85,20,d9,85,d9,86,20,d8,a7,d9,84,d9,85,d8,af,d9,8a,d8,b1,20,d8,a7,d9,84,d8,aa,d9,86,d9,81,d9,8a,d8,b0,d9,8a,20,d9,84,d9,84,d9,82
myuser@DB>select value from NLS_DATABASE_PARAMETERS where parameter LIKE '%CHARACTERSET';
VALUE
AR8MSWIN1256
UTF8Edited by: user560883 on May 4, 2012 3:34 AM
Edited by: user560883 on May 4, 2012 3:39 AM

Hi Sergiusz
Firstly I would like to thank you for replying.
Secondly I was able to move further with the DMU (the issue was due to more sessions that I had to kill to allow DMU to proceed with ALTER DATABASE CHARACTER SET command).
Here is what I have done so far without any luck.
1) Created a test instance with source database characterset ie AR8MSWIN1256 and performed a full import using DataPump (impdp).
2) Used DMU to perform conversion/migration to AL32UTF8. (this step took almost 5 hours).
3) Used SQLDeveloper to verify the results and data still show as garbage.
Thing that worked for me but is way to slow and not reliable.
1) Save data in file (.sql) using Windows XP client or windows 2003 server. Basically I am generating the whole SQL statements for UPDATE eg UPDATE table SET xx)
2) SET NLS_LANG=AMERICAN_AMERICA.UTF8 on command prompt of Windows XP client and use SQLPLUS to open sql prompt.
3) Use @path\file.sql (that was generated in earlier step) to update records.
4) Verify via SQLDeveloper that arabic shows correctly.
Issue with above approach is since we have millions of records stored in multiple tables, sometimes while generating the file with SQL Statements, the server CPU touch 100% and then freeze. Also file size grow exponentially and to verify how much of the work was done prior to freezing becomes very difficult.
I still have the DB after using the DMU tool intact so if you could think of some other workaround that will be great.
Again, thank you for helping me with this.

Issue related to Unicode character compatibility

Request for the help on the issue related to Unicode character compatibility with Oracle 11G R2 32 Bit DB.
Issue description: I have created a Profile in my application and named it with Unicode characters(German\Russian\Latvian…. alphabets), while opening the profile its throwing an error message “Invoice profile cannot be found in database.”
During the Oracle database installation I have selected the Database character set as Unicode UTF-8. As per our application guide it considers only the Database characterset and not the National character set.
Let me know if I have to still do some additional settings with respect to this globalization settings.
Thanks,
Brij

I don't know what the application does, so I don't also know the profile role and what - exactly - can't be found in the database. At least 'a invoice profile' is not a native Oracle object.
So it's not possible to analyze the application problem.
On the database side characterset UTF8 (although I would prefer the 'newer' AL32UTF8 characterset) is appropriate in a globalized environment. What to do in the interaction between application and database - that depends highly on the application itself.
Werner

AL32UTF8 characterset problem

Similar Messages

Maybe you are looking for