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

Similar Messages

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

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

Oracle database character set

Hello all -
Please help..................
I will be exporting/importing 6/7 users/schemas/data from one database to the another database on solaris. Users are created.
I am confused about NLS_LANG variable and database characterset.
I have the following questions -
1. What is impact of NLS_LANG variable setting of user session while import/export the data ?
2. Why do we need to set this NLS_LANG user session variable before export/import ?
3.If NLS_LANG variable is not set (doesnot have any value) what would happen ?
4. If I have to set NLS_LANG varible, what should I set it to?
5. How can I see the characterset of my database?
6. Where can I get more info about database charaterset and What are the valid values for database characterset and NLS_LANG varibale ?
Any help would really appreciated...
Thanks a lot.....
RAMA

1. What is impact of NLS_LANG variable setting of user session while import/export the data ?
On export, the data will be converted from the database character set to the character set specified by NLS_LANG. In import, the database will assume that the data is in the character set specified by NLS_LANG and use that value to perform the conversion to the database character set if the two values to not match.
2. Why do we need to set this NLS_LANG user session variable before export/import ?
If your database character set is the same as your OS, you don't necessarily have to set NLS_LANG. For instance, if you have a US7ASCII db, and your OS locale is set to AMERICA_AMERICAN.US7ASCII, there won't be any problems. The only time it's really important to set this is when the db and OS settings don't match.
3.If NLS_LANG variable is not set (doesnot have any value) what would happen ?
If your database character set doesn't match your OS, the data could be garbled because the db will incorrectly transcode the data on import/export.
4. If I have to set NLS_LANG varible, what should I set it to?
Depends on what your database character set is set to (see below).
5. How can I see the characterset of my database?
select * from nls_database_parameters and look for the value set for the NLS_CHARACTERSET parameter. Don't get confused by the NLS_NCHAR_CHARACTERSET, that's for NCHAR datatypes.
So, for instance, if your NLS_CHARACTERSET value is set to UTF8, you would set NLS_LANG to .UTF8 (the dot is important because that's actually shorthand for territory_language.characterset, or language_territory.characterset, I can never remember which comes first. In any case, use the dot). For example:
setenv NLS_LANG .UTF8
6. Where can I get more info about database charaterset and What are the valid values for database characterset and NLS_LANG varibale ?
It's all in the Oracle documentation.
hope this helps.
Tarisa.

How to change Database character set?

Hi,
We are planning to make a clone of production Database which has:
select value$ from sys.props$ where name='NLS_CHARACTERSET';
AL32UTF8
We have set up a new server for that purpose and installed database, but by default it has
select value$ from sys.props$ where name='NLS_CHARACTERSET';
WE8ISO8859P1
So after making full import from full backup file we have some broken character in database.
How can I change from WE8ISO8859P1 to AL32UTF8?
I expect that I need to shutdown the clone database or even make from scratch full import.
Thanks

I made a full backup from production database which has AL32UTF8
My new database is fresh and it has WE8ISO8859P1
I think the reason why I'm having some corrupted characters is because of difference in Character set between two database, right?
so I will need to change new database Character set to AL32UTF8 then make again full import.

Multilingual database character set.

Hi,
Our requirement is for multilingual.
So please tell me which database character set I have to set.
Also tell me other related parameters that have to set.
PratHamesh.

Hi, 
 
You can create your database in UTF8 mode. 
Read Database Globalization Support Guide for more info. 
 
Nicolas.

ORA-12709: error while loading create database character set

I installed Oracle 8.05 on Linux successfully: was able to login
whith SQLPlus, start and stop the db whith svrmgrl etc.
During this install I chose WE8ISO8859P9 as the database
characterset when prompted.
After that I installed Oracle Application Server 3.02, and now
I'm getting the
ORA-12709: error while loading create database character set
message when I try to start up the database, and the database
won't mount.
Platform is RedHat Linux 5.2.
NLS_LANG set to different settings,
e.g. AMERICAN_AMERICA.WE8ISO8859P9
but without success.
Anyone any clue?
Thanks!
null

Jogchum Reitsma (guest) wrote:
: I installed Oracle 8.05 on Linux successfully: was able to
login
: whith SQLPlus, start and stop the db whith svrmgrl etc.
: During this install I chose WE8ISO8859P9 as the database
: characterset when prompted.
: After that I installed Oracle Application Server 3.02, and now
: I'm getting the
: ORA-12709: error while loading create database character set
: message when I try to start up the database, and the database
: won't mount.
: Platform is RedHat Linux 5.2.
: NLS_LANG set to different settings,
: e.g. AMERICAN_AMERICA.WE8ISO8859P9
: but without success.
: Anyone any clue?
: Thanks!
You can create the database with WE8DEC character set
and to use the WE8ISO8859P9 on the client or even on Linux.
The NLS_LANG setting doesn't effect the database, but the
interface with the database. The same setting can be used in de
windows 95/98/NT registry.
null

Changing database character set from US7ASCII to AL32UTF8

Our database is running on Oracle database 10.1.0.4.0 (AIX) The following are its parameters:
SQL> select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';
VALUE
US7ASCII
We would like to change the database character set to AL32UTF8. After following Metalink notes: 260192.1 (which helped us resolve "Lossy" and "Truncated" data, the final output of the CSSCAN utility is:
[Scan Summary]
All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set
[Data Dictionary Conversion Summary]
The data dictionary can be safely migrated using the CSALTER script
We have no (0) Truncation and Lossy entries on the .txt file. We only have Changeless and Convertible. Now accdg to the documentation, we can do a FULL EXP and FULL IMP. But it did not detail how to do the conversion on the same database. The discussion on the document tells how to do it from one database to another database. But how about on the same database?
We cannot use CSALTER as stated on the document.
(Step 6
Step 12
12.c) When using Csalter/Alter database to go to AL32UTF8 and there was NO "Truncation" data, only "Convertible" and "Changeless" in the csscan done in point 4:)
After performing a FULL export of the database, how can we change its character set? What do we need to do the the existing database to change its character set to AL32UTF8 before we import back our dump file into the same database?
Please help.

There you are! Thanks! Seems like I am right in my understanding about the Oracle Official Documentation. Thanks!
Hmmmmm...when you say:
*"you can do selective export of only convertible tables, truncate the tables, use CSALTER, and re-import."*
This means that:
1. After running csscan on database PROD, i will take note of the convertible tables in the .txt output file.
2. Perform selective EXPORT on PROD (EXP the convertible tables)
3. Truncate the convertible tables on PROD database
4. Use CSALTER on PROD database
5. Re-import the tables into PROD database
6. Housekeeping.
Will you tell me if these steps are the correct one? Based on our scenario: This is what i have understood referring to the Official Doc.
Am i correct?
I really appreciate your help Sergiusz.

How to review implication of database character set change on PL/SQL code?

Hi,
We are converting WE8ISO8859P1 oracle db characterset to AL32UTF8. Before conversion, i want to check implication on PL/SQL code for byte based SQL functions.
What all points to consider while checking implications on PL/SQL code?
I could find 3 methods on google surfing, SUBSTRB, LENGTHB, INSTRB. What do I check if these methods are used in PL/SQL code?
What do we check if SUBSTR and LENGTH functions are being used in PL/SQl code?
What all other methods should I check?
What do I check in PL/SQL if varchar and char type declarations exist in code?
How do i check implication of database characterset change to AL32UTF8 for byte bases SQL function.
Thanks in Advance.
Regards,
Rashmi

There is no quick answer. Generally, the problem with PL/SQL code is that once you migrate from a single-byte character set (like WE8ISO8859P1) to a multibyte character set (like AL32UTF8), you can no longer assume that one character is one byte. Traditionally, column and PL/SQL variable lengths are expressed in bytes. Therefore, the same string of Western European accented letters may no longer fit into a column or variable after migration, as it may now be longer than the old limit (2 bytes per accented letter compared to 1 byte previously). Depending on how you dealt with column lengths during the migration, for example, if you migrated them to character length semantics, and depending on how relevant columns were declared (%TYPE vs explicit size), you may need to adjust maximum lengths of variables to accommodate longer strings.
The use of SUBSTR, INSTR, and LENGTH and their byte equivalents needs to be reviewed. You need to understand what the functions are used for. If the SUBSTR function is used to truncate a string to a maximum length of a variable, you may need to change it to SUBSTRB, if the variable's length constraint is still declared in bytes. However, if the variable's maximum length is now expressed in characters, SUBSTR needs to be used. However, if SUBSTR is used to extract a functional part of a string (e.g. during parsing), possibly based on result from INSTR, then you should use SUBSTR and INSTR independently of the database character set -- characters matter here, not bytes. On the other hand, if SUBSTR is used to extract a field in a SQL*Loader-like fixed-format input file (e.g. read with UTL_FILE), you may need to standardize on SUBSTRB to make sure that fields are extracted correctly based on defined byte boundaries.
As you see, there is universal recipe on handling these functions. Their use needs to be reviewed and understood and it should be decided if they are fine as-is or if they need to be replaced with other forms.
Thanks,
Sergiusz

Approach to converting database character set from Western European to Unicode

Hi All,
EBS:12.2.4 upgraded
O/S: Red Hat Linux
I am looking for the below information. If anyone could help provide would be great!
INFORMATION NEEDED: Approach to converting database character set from Western European to Unicode for source systems with large data exceptions
DETAIL: We are looking to convert Oracle EBS database character set from Western European to Unicode to support Kanji characters. Our scan results show
both “lossy (110K approx.)” and “truncation (26K approx.)” exceptions in the database which needs to be fixed before the database is converted to Unicode.
Oracle Support has suggested to fix all open and closed transactions in the source Production instance using forms and scripts.
We’re looking for information/creative approaches who have performed similar exercises without having to manipulate data in the source instance.
Any help in this regard would be greatly appreciated!
Thanks for yourn time!
Regards,

There are two aspects here:
1. Why do you have such large number of lossy characters? Is this data coming from some very old eBS release, i.e. from before the times of the Java applet interface to Oracle Forms? Have you analyzed the nature of this lossy data?
2. There is no easy way around truncation issues as you cannot modify eBS metadata (make columns wider). You must shorten or remove the data manually through the documented eBS interfaces. eBS does not support direct manipulation of data in the database due to complex consistency rules enforced by the application itself (e.g. forms).
Thanks,
Sergiusz

How to alter database character set from AL32UTF8 to EE8MSWIN1250

Hi folks,
I'm using an Oracle 10g, XE database, which has a database character set set to AL32UTF8, what causes that some characters like "č ť ř ..." are not displayed.
To fix this issue, I would like to change it to EE8MSWIN1250 character set as it's set on server.
Unfortunatelly below steps don;t work for me:
connect sys as sysdba;
SHUTDOWN IMMEDIATE;
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 NATIONAL CHARACTER SET EE8MSWIN1250;
ALTER DATABASE CHARACTER SET EE8MSWIN1250;
SHUTDOWN IMMEDIATE; -- or SHUTDOWN NORMAL;
STARTUP;Value in regedit: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_XE is set to CZECH_CZECH REPUBLIC.EE8MSWIN1250
I'm struggling with this issue for hours and unfortunatelly can't make it work. Any advise is more than welcome.
Thanks,
Tomas
I tried to use hints listed here , but always getting some ORA messages.

Hi Sergiusz,
Thank you for your reply. You're right, I've probably didn't provide a full details about my issue, but at least now I know, that database encoding(characterset) is correct.
Here is my issue:
Within my APEX application I would like to use a JasperReportsIntegration, so to be able to create and run iReports straight from APEX application. Installation, and implementation of JasperReports works fine, I had no issue with it.
As a second step I've created a simple report using iReport tool, when if preview function is used, all static characters (from report labels) are displayed correctly. Database items are displayed incorectly - some Czech characters are not displayed. Language within report is set to cs_CS, but I've tried also other options. No sucess.
When I run that report from APEX application (from server) then the same issue - data from database are returned without some czech characters.
Kind regards,
Tomas

USER_FILTER and database character set

Hello,
I'm currently working on the integration of a tool into Oracle Text for filtering PDFs. My current approach is to call a command line tool via a USER_FILTER preference, and this works fine as long as the database character set is AL32UTF8. The tool is creating the filtered text as UTF-8.
I'm struggling now with the case that the database character set is not Unicode, for example LATIN1. I had hoped that I can specify a chain of filters for this situation when creating the index, first a USER_FILTER to get the text out of the document and then a CHARSET_FILTER to convert the filtered text from UTF-8 into the database character set. This is my attempt to set this up:
execute ctx_ddl.create_preference ('my_pdf_datastore', 'file_datastore')
execute ctx_ddl.create_preference ('my_pdf_filter', 'user_filter')
execute ctx_ddl.set_attribute ('my_pdf_filter', 'command', 'tetfilter.bat')
execute ctx_ddl.create_preference('my_cs_filter', 'CHARSET_FILTER');
execute ctx_ddl.set_attribute('my_cs_filter', 'charset', 'UTF8');
create index tetindex on pdftable (pdffile) indextype is ctxsys.context parameters ('datastore my_pdf_datastore filter my_pdf_filter filter my_cs_filter');
These are the error messages I'm getting (sorry, German Windows):
FEHLER in Zeile 1:
ORA-29855: Fehler bei Ausf³hrung der Routine ODCIINDEXCREATE
ORA-20000: Oracle Text-Fehler:
DRG-11004: Doppelter oder unvereinbarer Wert f³r FILTER
ORA-06512: in "CTXSYS.DRUE", Zeile 160
The relevant message is DRG-11004, which translates to "duplicate or incompatible value for FILTER".
ORA-06512: in "CTXSYS.TEXTINDEXMETHODS", Zeile 364
So here is my question:
Do I understand it correctly that with the USER_FILTER the text is always expected in the database encoding, and that it is mandatory to create the filtered text in the database character set, or are there any alternatives?
Thanks
Stephan

The previous experiments were performed with Oracle 10i. I just saw that in Oracle 11.1.0.7 there is this new feature: "USER_FILTER is now sensitive to FORMAT and CHARSET columns for better indexing performance.".
This seems to be exactly what I was looking for.
Regards
Stephan

Arabic text shows junk in database character set

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

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

Database character set

Hi brother,
I would like to create new DB which support Simplified Chinese and Traditional Chinese. which character should I choose?
Thanks

If you for some reason don't want to use Unicode ie. AL32UTF8, then for database character set (not national character set), see the Recommended list, table A-4:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/applocaledata.htm#i635016
If you also include "other" character sets, there are several, beginning with ZH that seem to support Chinese language.

Change Database Character Set to Arabic!

Dear All,
My database is Oracle 11gR2 On Linux platform.
I am trying to change the character set of my database to store Arabic characters.
This is what I am doing:
SHUTDOWN IMMEDIATE;
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 INTERNAL_USE AR8ISO8859P6;
SHUTDOWN IMMEDIATE;
STARTUP;
When i check:
SQL> select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';
VALUE
AR8ISO8859P6
But still when i query data it shows it like this:
"¿¿¿¿¿¿ç ¿¿ê ¿¿¿¿çê¿ ¿¿¿¿ ¿¿¿ ¿¿¿¿¿¿ ¿¿¿¿ ¿¿¿èê¿ ¿¿¿è¿ ¿¿¿¿ê¿¿ ¿¿¿ ¿¿â¿¿ ¿¿é ¿¿¿ è¿¿¿ ¿ê ¿¿¿¿ êè¿ ¿¿¿¿¿¿ 28/9 ¿ê ¿ ¿¿é ¿¿¿¿ ¿è¿¿ê èç¿¿¿ ¿è¿¿¿ âê¿¿ ¿¿¿ è¿¿â¿ ¿¿è¿"
Can you help me to understand where is the problem and how to get through it.
Regards, Imran

Why on earth are you using the undocumented INTERNAL_USE command? The name alone should strongly imply that this isn't something that normal users should be playing with. It is extremely likely that you've corrupted your database.
Do you have a backup of your database taken before you corrupted it? If so, can you restore that backup? Once you do that, tell us what character set you're starting with. If you are implying that there is existing data in the database, what character set is that data encoded with? Can you DUMP the data to verify this?
Justin

Why that database Character set is required

Similar Messages

Maybe you are looking for