NLS_LANG conversion

Hi All
Ihave problem with importin data
import done in AR8ISO8859P6 character set and AR8ISO8859P6 NCHAR character set
export client uses WE8ISO8859P1 character set (possible charset conversion)
export server uses WE8ISO8859P1 NCHAR character set (possible ncharset conversion)
my data writing in arabic , now I see it qutaion mark(??????????)

It look like while exporting you had western character set not arabic character set.
Set the nls_lang as per your requirement and take an export again. Then, do the import with the same nls_lang settings.
sjh
ocp dba

Similar Messages

JDBCPDS error runtime

hi all,
i get error :
REP-4100 : data source execution fail
JDBCPDS- 62008 : conversion fail between UTF8 and UCS2 fail UTF8Conv.
Can anyone tell me some solutions

Hi Thierno
It may be the case that the NLS_LANG setting in your developer env is different then the DB lang settings. It is failing in the NLS_LANG conversion. I suggest you apply the Reports+Forms Integrated patch-1 on your setup. You can download the patch from Metalink site. In 902 base release, there was an issue also with JDBCPDS when your NLS_LANG setting in developer are not the default ascii one. The JDBC driver use to convert the locale settings to UTF-8. Integrated patch-1 solves this issue.
Thanks
Rohit

Character conversion and NLS_LANG

Hi,
The Oracle doc says that character encoding conversion for Java programs using the OCI driver is dependent on NLS_LANG. But the description of this was a bit confusing. As per the doc
"The JDBC OCI driver transfers the data from the server to the client in the character set of the database. Depending on the value of the NLS_LANG environment variable, the driver handles character set conversions in one of two ways.
1)If the value of NLS_LANG is not specified, or if it is set to the US7ASCII or WE8ISO8859P1 character set, then the JDBC OCI driver uses Java to convert the character set from US7ASCII or WE8ISO8859P1 directly to UCS-2.
2)If the value of NLS_LANG is set to a non-US7ASCII or non-WE8ISO8859P1 character set, then the driver changes the value of the NLS_LANG parameter on the client to UTF-8. This happens automatically and does not require any user-intervention. OCI uses the value of NLS_LANG to convert the data from the database character set to UTF-8; the JDBC driver then converts the UTF-8 data to UCS-2. "
Now refering to case1, assume the database character set is multibyte.Does this mean that the OCI C libraries first convert this to US7ASCII or WE8ISO8859P1 and then the Java driver does the conversion from US7ASCII or WE8ISO8859P1 directly to UCS-2. If that is the case, wouldnt information get lost during the first conversion.
Thanks,
Tom.

"Now refering to case1, assume the database character set is
multibyte.Does this mean that the OCI C libraries first convert
this to US7ASCII or WE8ISO8859P1 and then the Java driver
does the conversion from US7ASCII or WE8ISO8859P1 directly to
UCS-2. If that is the case, wouldnt information get lost during
the first conversion. "
Yes this is true. For a multibyte database character set caution
must be taken that the client application NLS_LANG is not
US7ASCII or WE8ISO8859P1 or data loss can occur. An effort will
be made to remove the NLS_LANG dependency in a future release
because the current solution is imperfect.

Export/import character data conversion in NLS_LANG FAQ

The [OTN NLS_LANG FAQ|http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm#_Toc110410566] says:
>
In Oracle9i the Export utility always exports user data, including Unicode data, in the character set of the database. The Import utility automatically converts the data to the character set of the target database.
>
But I don't think this is correct for Oracle 9i. Example:
export NLS_LANG=AMERICAN_AMERICA.US7ASCII
sqlplus /
SQL*Plus: Release 9.2.0.6.0 - Production on Wed Jun 17 10:05:57 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
JServer Release 9.2.0.6.0 - Production
SQL> select * from v$version;
BANNER
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
PL/SQL Release 9.2.0.6.0 - Production
CORE    9.2.0.6.0       Production
TNS for HPUX: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
SQL> select * from nls_database_parameters where parameter like '%SET%';
PARAMETER                      VALUE
NLS_CHARACTERSET               WE8ISO8859P15
NLS_NCHAR_CHARACTERSET         AL16UTF16
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
JServer Release 9.2.0.6.0 - Production
exp / owner=test file=test.dmp
Export: Release 9.2.0.6.0 - Production on Wed Jun 17 10:06:42 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
JServer Release 9.2.0.6.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P15 character set (possible charset conversion)
About to export specified users ...Could you please:
- check and update NLS_LANG FAQ for Oracle 9i
- update NLS_LANG FAQ for Oracle 10g, Oracle 11g and Data Pump.
Thanks.
Edited by: P. Forstmann on Jun 17, 2009 10:14 AM

I was wrong and you are right like the OTN NLS_LANG FAQ.
I made the following test with Oracle 9.2.0.6 and with Oracle XE:
sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Ven. Juin 19 10:20:23 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connecté à :
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> create table t (x varchar2(10));
Table créée.
SQL> insert into t values(chr(233));
1 ligne créée.
SQL> select * from t;
X
é
SQL> select dump(x,1017) from t;
DUMP(X,1017)
Typ=1 Len=1 CharacterSet=WE8MSWIN1252: e9
SQL> exit
Déconnecté de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
set NLS_LANG=AMERICAN_AMERICA.US7ASCII
exp test/test tables=t file=t.dmp
Export: Release 10.2.0.1.0 - Production on Fri Jun 19 10:21:54 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8MSWIN1252 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
. . exporting table                              T          1 rows exported
Export terminated successfully without warnings.
sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jun 19 10:22:07 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> drop table t;
Table dropped.
SQL> exit
Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
imp test/test tables=t file=t.dmp
Import: Release 10.2.0.1.0 - Production on Fri Jun 19 10:22:23 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Export file created by EXPORT:V10.02.01 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8MSWIN1252 character set (possible charset conversion)
. importing TEST's objects into TEST
. importing TEST's objects into TEST
. . importing table                            "T"          1 rows imported
Import terminated successfully without warnings.
sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jun 19 10:22:32 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SQL> select dump(x,1017) from t;
DUMP(X,1017)
Typ=1 Len=1 CharacterSet=WE8MSWIN1252: e9

Arabic Character set conversion-help needed

We have our main database running in 10g (Solaris o/s) & planning to move these to RAC 11g.
One of our old oracle DB(8.0.5)/solaris, which is not used till recently need to upgrade to 10g Rel2.
I know Supported direct upgrade 8.0.6/8.1.7/9i -> 10g
Current DB: 8.0.5 (Character Set: AR8ISO8859P6)
Target DB : 10g Rel 2 (Character Set: AR8MSWIN1256)
I am thinking to go the following way by using exp/imp
8.0.5(AR8ISO8859P6) -> 8.1.7(AR8ISO8859P6) -> 10G(AR8MSWIN1256)
OR
8.0.5(AR8ISO8859P6) -> 8.1.7(AR8MSWIN1256) -> 10G(AR8MSWIN1256)
please advice
thanks

(1) At source db 8.0.5 (solaris)
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-YY
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET AR8ISO8859P6
NLS_SORT BINARY
NLS_NCHAR_CHARACTERSE T AR8ISO8859P6
$set NLS_LANG=AMERICAN_AMERICA.AR8ISO8859P6
$exp sys/dba file=full251109.dmp full=y
(2):>> At target db 10g R2 (solaris)
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RRRR
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET AR8ISO8859P6
NLS_SORT BINARY
NLS_NCHAR_CHARACTERSET UTF8
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
$export NLS_LANG=AMERICAN_AMERICA.AR8ISO8859P6
$imp testdba/testdba file=full251105.dmp fromuser=PROFINAL touser=PROFINAL
*$csscan testdba/testdba FULL=Y FROMCHAR=AR8ISO8859P6 TOCHAR=AR8ISO8859P6 LOG=P6check CAPTURE=Y ARRAY=100000 PROCESS=2*
There is EXCEPTIONAL DATA in .err file+
clients accessing 8.0.5 dataabase uses characterset AR8IS08859P6, which is SAME as 8.0.5 database
-CSSCAN result->>[Database Scan Parameters]
Parameter Value
CSSCAN Version v2.1
Instance Name MIG1
Database Version 10.2.0.1.0
Scan type Full database
Scan CHAR data? YES
Database character set AR8ISO8859P6
FROMCHAR AR8ISO8859P6
TOCHAR AR8ISO8859P6
Scan NCHAR data? NO
Array fetch buffer size 100000
Number of processes 2
Capture convertible data? YES
[Scan Summary]
Some character type data in the data dictionary are not convertible to the new
haracter set Some character type application data are not convertible to the new characters
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 2,235,403 0 0 *1,492*
CHAR 1,097 0 0 0
LONG 155,188 0 0 6
CLOB 24,643 0 0 0
VARRAY 21,352 0 0 0
Total 2,437,683 0 0 1,498
Total in percentage 99.939% 0.000% 0.000% 0.061%
The data dictionary can not be safely migrated using the CSALTER script
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 16,986,594 0 0 *1,240,383*
CHAR 164,114 0 0 0
LONG 7 0 0 0
CLOB 1 0 0 0
VARRAY 1,436 0 0 0
Total in percentage 93.256% 0.000% 0.000%
6.744%
[Distribution of Convertible, Truncated and Lossy Data by Table]
USER.TABLE Convertible Truncation Lossy
PROFINAL.BASE_MASTER_DATAS 0 0 *362,003*
PROFINAL.CODE_ALLOW 0 0 *53*
PROFINAL.CODE_ALLOWANCE_TYPES 0 0 *1*
PROFINAL.CODE_BONUS_TYPES 0 0 *2*
PROFINAL.CODE_BRANCHES 0 0 *2*
PROFINAL.CODE_CERTIFICATES 0 0 *94*
Kindly help,,,
Edited by: userR12 on Nov 25, 2009 1:43 AM
Edited by: userR12 on Nov 25, 2009 1:52 AM

Supplier conversion into R12 giving error at site level(AP_INVALID_TCA_ERR)

Hi All,
I am running "Supplier Sites Open Interface Import" for Supplier Site conversion but standard program is failing with the following error msg: "AP_INVALID_TCA_ERROR".
Can any one please help me how I can fix this issue. Any help will be Gold for me.
Best Regards,
Shaik.

Hi Hussein,
OS: Linux.
DataBase: Oracle 11g
Application is : Oracle R12.2
Below is the coucurrent request Log.
Payables: Version : 12.0.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
APXSSIMP module: Supplier Sites Open Interface Import
Current system time is 09-NOV-2010 02:48:40
+-----------------------------
| Starting concurrent program execution...
+-----------------------------
Arguments
P_WHAT_TO_IMPORT='ALL'
P_COMMIT_SIZE='50000'
P_PRINT_EXCEPTIONS='N'
P_DEBUG_SWITCH='Y'
P_TRACE_SWITCH='Y'
APPLLCSP Environment Variable set to :
Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :
American_America.AL32UTF8
Enter Password:
MSG-00001: After SRWINIT
MSG-00002: After Get_Company_Name
MSG-00003: After Get_NLS_Strings
MSG-00004: After Importing Suppliers
MSG-00005: After Get_Header_Information
MSG-00020: After SRWEXIT
Report Builder: Release 10.1.2.3.0 - Production on Tue Nov 9 02:48:43 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Executing request completion options...
Output file size:
2369
------------- 1) PRINT   -------------
Printing output file.
Request ID : 1446582
Number of copies : 0
Printer : noprint
Finished executing request completion options.
Concurrent request completed successfully
Current system time is 09-NOV-2010 02:48:54
Best Regards,
Shaik

How to setup NLS_LANG on Windows XP

Hi,
We have an oracle database with character set AMERICAN_AMERICA.US7ASCII setting. and our
production application inserts different language characters directly to the database without any
UTF8 conversion. Another function has been coded which can convert the different character set
to UTF8 via using convert() function before the client side can be used. it has been proved it works
fine with a PHP application which can show UTF8 on the webpage, based on a unix-box server.
Now I have installed a oracle application express server with character set AMERICAN_AMERICA.WE8MSWIN1252
(found from registry) on my windows XP. After reading the article from metalink
https://metalink.oracle.com/metalink/plsql/f?p=130:14:1393556852351104955::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,158577.1,1,1,1,helvetica
, I understood that oracle server side would convert the character to the client side if it found
their character set are difference, which is not what I want in this case, so I should set my client side as same as
server side so that no any conversion therefore the converted UTF8 code can directly delivered to front application.
I have try to set the oracle client side as AMERICAN_AMERICA.US7ASCII, WE8ISO8859P1 or others, none of them works.
Give you a simple instance here is that
1.Insert ZHS16CGB231280(chinese code) to Production database(US7ASCII)
2. retreive it by convert('string', 'UTF8', 'ZHS16CGB231280')
3. send to client side(characterset US7ASCII)
doesn't work
Does anyone has experience and point me out what wrong it is. it lasts me several weeks trying to
figure out, but failure.
Thanks for your help
Eric
[email protected]

Generally speaking, if you want to store chinese characters, your database character set must be able to store it correctly without using CONVERT function: you could use one of the
universal character set. I'm surprised that you are able to store chinese characters in the US7ASCII character set but I'm not surprised that it does not work in other cases.
The OTN NLS_LANG FAQ give some common values under Windows, assuming that each Windows node will only be used in one given national environment.

XML data from BLOB to CLOB - character set conversion

Hi All,
I'm trying to solve a problem with a character set conversion in PL/SQL in the following scenario:
1. source is an XML as a BLOB variable.
2. target is an XML as a CLOB variable.
3. the problem I have is the following:
- database character set is set to UTF-8
- XML character set could be anything (UTF-8, ISO 8859-1, ISO 8859-2, ASCII, ...)
- I need to write a procedure which converts the source BLOB content into the target CLOB taking into account the XML encoding and converts it into the DB default character set (UTF8).
I've been able to implement a simple conversion function. However, this function expects static XML encoding ISO-8859-1. The main part of the function looks as follows:
buffer := UTL_RAW.cast_to_varchar2(
UTL_RAW.convert(
DBMS_LOB.SUBSTR(source_blob_variable, 16000, pos)
, 'American_America.UTF8'
, 'American_America.we8iso8859p1')
Does anyone have an idea how to rewrite the code to handle "any" XML encoding in the source BLOB file? In other words, is there a function in Oracle which converts XML character set names into Oracle character set values (ISO-8859-1 to we8iso8859p1, UTF-8 to UTF8, ...)?
Thanks a lot for any help.
Julius

I want to pass a BLOB to some "createXML" procedure and get a proper XMLType in UTF8 character set, properly converted from whatever character set is the input in.As per documentation the generated XML has always the encoding set at the client side depending on NLS_LANG (default UTF-8), regardless of the input encoding, so I don't see a need to parse the PI of the XML:
C:\>echo %NLS_LANG%
%NLS_LANG%
C:\>sqlplus
SQL*Plus: Release 11.1.0.6.0 - Production on Wed Apr 30 08:54:12 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> var cur refcursor
SQL>
SQL> declare
2     b   blob := utl_raw.cast_to_raw ('<a>myxml</a>');
3 begin
4     open :cur for select xmlroot (xmltype (utl_raw.cast_to_varchar2 (b))) xml from dual;
5 end;
6 /
PL/SQL procedure successfully completed.
SQL>
SQL> print cur
XML
<?xml version="1.0" encoding="UTF-8"?><a>myxml</a>
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
C:\>set NLS_LANG=GERMAN_GERMANY.WE8ISO8859P1
C:\>sqlplus
SQL*Plus: Release 11.1.0.6.0 - Production on Mi Apr 30 08:55:02 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> var cur refcursor
SQL>
SQL> declare
2     b   blob := utl_raw.cast_to_raw ('<a>myxml</a>');
3 begin
4     open :cur for select xmlroot (xmltype (utl_raw.cast_to_varchar2 (b))) xml from dual;
5 end;
6 /
PL/SQL-Prozedur erfolgreich abgeschlossen.
SQL>
SQL> print cur
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
<a>myxml</a>

Conversions between character sets when using exp and imp utilities

I use EE8ISO8859P2 character set on my server,
when exporting database with NLS_LANG not set
then conversion should be done between
EE8ISO8859P2 and US7ASCII charsets, so some
characters not present in US7ASCII should not be
successfully converted.
But when I import such a dump, all characters not
present in US7ASCII charset are imported to the database.
I thought that some characters should be lost when
doing such a conversions, can someone tell me why is it not so?

Not exactly. If the import is done with the same DB character set, then no matter how it has been exported. Conversion (corruption) may happen if the destination DB has a different character set. See this example :
[ora102 work db102]$ echo $NLS_LANG
AMERICAN_AMERICA.WE8ISO8859P15
[ora102 work db102]$ sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:47:01 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
TEST@db102 SQL> create table test(col1 varchar2(1));
Table created.
TEST@db102 SQL> insert into test values(chr(166));
1 row created.
TEST@db102 SQL> select * from test;
C
¦
TEST@db102 SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
[ora102 work db102]$ export NLS_LANG=AMERICAN_AMERICA.EE8ISO8859P2
[ora102 work db102]$ sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:47:55 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
TEST@db102 SQL> select col1, dump(col1) from test;
C
DUMP(COL1)
©
Typ=1 Len=1: 166
TEST@db102 SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
[ora102 work db102]$ echo $NLS_LANG
AMERICAN_AMERICA.EE8ISO8859P2
[ora102 work db102]$ exp test/test file=test.dmp tables=test
Export: Release 10.2.0.1.0 - Production on Tue Jul 25 14:48:47 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export done in EE8ISO8859P2 character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P15 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
. . exporting table TEST 1 rows exported
Export terminated successfully without warnings.
[ora102 work db102]$ sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:48:56 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
TEST@db102 SQL> drop table test purge;
Table dropped.
TEST@db102 SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
[ora102 work db102]$ imp test/test file=test.dmp
Import: Release 10.2.0.1.0 - Production on Tue Jul 25 14:49:15 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Export file created by EXPORT:V10.02.01 via conventional path
import done in EE8ISO8859P2 character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P15 character set (possible charset conversion)
. importing TEST's objects into TEST
. importing TEST's objects into TEST
. . importing table "TEST" 1 rows imported
Import terminated successfully without warnings.
[ora102 work db102]$ export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
[ora102 work db102]$ sqlplus test/test
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 25 14:49:34 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
TEST@db102 SQL> select col1, dump(col1) from test;
C
DUMP(COL1)
¦
Typ=1 Len=1: 166
TEST@db102 SQL>

Conversions between character sets when using 'exp' and 'expdp' utilities

When I make export with exp utility with NLS_LANG environment
variable not set, export is done with US7ASCII character set,
but when server uses some other character set e.g. EE8ISO8859P2,
there can be some national specific characters lost with such a conversion.
But when I use expdp utility and have not NLS_LANG set,
in log file there is not mentioned that export is done in other character set
than that on the server, does it mean that it uses character set on server?

When I make export with exp utility with NLS_LANG environment
variable not set, export is done with US7ASCII character set,
but when server uses some other character set e.g. EE8ISO8859P2,
there can be some national specific characters lost with such a conversion.
But when I use expdp utility and have not NLS_LANG set,
in log file there is not mentioned that export is done in other character set
than that on the server, does it mean that it uses character set on server?

Character set conversion

I have had problems with extended charaters
in a database table not being represented
correctly by clients. I believe that the FAQ
concerning "Why do I see questions marks..."
identified the problems. The database is set
to Latin4 and clients at Latin1. I am seeing
inverted questions marks for characters that
don't match when displaying the table on
a client, whether SQLPLUS under NT4.0, SQLPLUS under Solaris 8, even ODBC to MS Access.
My questions are
1) How do the database and clients know
that the character sets are different? We
at first assumed that only the bit patterns
were seen so we might see different characters for the same 8 bits.
2) How are the character sets compared?
3) If a character is moved to a different
bit pattern, is this recognized and hadled
properly? Or is it only matching characters
with the same bit pattern?
Answers will be greatly appreciated after
weeks of asking questions outside this forum
and searching the WWW.
Thanks,
Dave

Hi,
You didn't mention what your nls_lang setting on your client is set to. Your NLS_LANG setting for Windows should reflect your current code page. In general two scenarios can occur
when data is sent from client to the database. If the database character set and client NLS_LANG match then no conversion takes place. Otherwise the data is automatically converted converted from the client code page to the database character set and vice versa. In either of these two scenarios if the NLS_LANG is set improperly (not reflecting current client OS code) corruption can occur. In the scenario you are describing have you entered non Latin1 data into the database? If so how? If you have, and it was entered properly you will still have difficulties displaying the data in SQL*PLUS on a Latin1 client as it will not know about these characters. Another tactic that would be useful is to use the dump command to see if your latin4 characters are stored properly on the database. An example would be something like: SELECT DUMP(col,1016)FROM table ;
null

Import error character set conversion

import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses WE8ISO8859P1 character set (possible charset conversion)
Import terminated successfully without warnings.
how to resolve this
importinng into linux machine

import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses WE8ISO8859P1 character set (possible charset conversion)
Import terminated successfully without warnings.Your import was successful. However, there are a few things you need to note from the top of the import log. It is advisable to use correct NLS settings when doing export/import to avoid data corruption/loss. That idea is to ensure you set the correct NLS setting (NLS_LANG) at the client before running exp or imp. In some cases, the setting does not matter because the different character sets can go together.
In this case, I would not worry about it.

Nls_lang for psp with Traditional Chinese

I have two Oracle environments:
1. Oracle 817 on Windows 2000 (eng) with Traditional Chinese as default locale, and
2. Oracle 816 on Solaris with Oracle 9iAS portal.
in both environment, I wanted to create a simple page as follows:
<html>
<head>
<title>Welcome</title>
<meta http-equiv="content-type" content="text/html; charset=big5">
</head>
<body>
<h3>Welcome to this page</h3>
Welcome Here
</body>
</html>
If I put this page under a virtual directory of Apache, the client browser would change the encoding to Traditional Chinese (Big 5) if "Auto-Select" is selected in encoding. Now, I try to put this in a psp. The page comes up with encoding change to "Western European (ISO)". I view the source from the page and it is just the same as the one under a virtual directory of Apache.
Why does this happen?
How can I make the client browser change to "Traditional Chinese (Big 5)" encoding?
I tried to set the NLS_LANG before using loadpsp but that didn't make any difference. Any idea?

Do you mean that I will have problem later if I don't change the database character set?Yes , definitely. What you are doing is storing invalid multibyte characters into a single byte database. So each double byte BIG5 characters are being treated as 2 separate WE8ISO8859P1 (Latin1) characters. You are using an unsupported but common garbage in garbage out approach, so in that sense you are using Oracle as a garbage container :) .
Let's look at some of the issues that you are going to have :-
All SQL Functions are based on the property on the database character set WE8ISO8859P1. So LENGTH(), SUBSTR (), INSTR (), UPPER(), NLS_UPPER etc .. will yield incorrect results . For example a column with one BIG5 character and one ASCII character will return a length of 3 characters rather than 2 characters. And if you want to locate a specific character in a mix ASCII and BIG5 string using the SUBSTR() it will be very difficult, because to Oracle the string consists of all single byte Latin1 characters, it will not skip 2 bytes for a BIG5 character. Even if you don't have mix strings, you will need to have one routine for handling ASCII only and another for BIG5 strings.
Invalid Data conversion , if your need to talk to another db using dblink say ,all the character conversion will be based on Latin1 to the target database character set mapping, so the receiver will lose all the source BIG5 characters and will get 2 Latin1 characters for each BIG5 char instead .
Export and Import will have identical problems, character set conversion are performed during these operations, so all BIG5 characters will be lost. This also means that you can not load BIG5 data into your current DB using IMPORT or SQLLOADER without data corruption ...
null

Conversion from UTF to EBCDIC format- Urgent

I want to convert the data from UTF* format to EBCDIC format and create a flat file for the same. Is there any utility tools available in oracle. If not what are the other possibilities? pls help me.
Thanks
Krishnaraj

Hi ,
I am trying to convert the normal text data to EBCDIC. As we all know, there is a corresponding value for each normal character in ASCII/HEX/BINARY/EBCDIC etc.
Using CONVERT I am able to see some data converted correctly but rest of hte accented characters not correctly.
select convert('^', 'US7ASCII','EBCDIC' ) from dual;
select convert(';' ,'WE8EBCDIC500','US7ASCII') from dual;
^ = ascii normal txt
; = corresponding ebcdic of ^
Internally CONVERT function seems to be doing correct conversion but there is a problem wiht the actually new - to be replaced characters. SQLPLUS is not able to display all the characters correctly. For all the accented chars of "a", it shows plain english a, same wiht e , u etc.
I would like to know is there anyone who knows what client side settings need to be done so that the CONVERT function output is displayed correctly on SQLPLUS.
I am using Oracle 9i Rel 2
NLS_LANG on my client (win XP) is set to AMERICAN_AMERICA.WE8MSWIN1252
As seen in the CONVERT function, the correct charset is - 'WE8EBCDIC500'
And the db params are as follows --
===========================================
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 WE8ISO8859P1
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 9.2.0.1.0
===================================================
Can anyone help me on this??
Thanks in advance
regards
Abhivyakti,
Pune, India

Effect of NLS_LANG in SQL scripts

DB version: 11.2.0.2
Platform : RHEL 5.6
We have a software vendor who occasionaly sends us SQL scripts to deploy.
The scripts will usually contain few DDLs and lots DMLs
From textpad, i can the see the DMLs (INSERTs , UPDATEs) in SQL Script. It usually contain non-english characters (Dutch, German, French) like
'Übersicht Buchungssätze' .
'Fehler beim Löschen der zugeordneten Referenzen!'They always ask us to set NLS_LANG like following.
export NLS_LANG="AMERICAN_AMERICA.WE8ISO8859P15"After the INSERT, I queried the inserted values from PL/SQL developer. The values appear as it appears in the SQL Script text file as shown above.
So, what was the effect of setting NLS_LANG ? What could have happened if I hadn't set NLS_LANG ?
NLS info within out DB
SQL > select * from nls_Database_parameters;
PARAMETER                      VALUE
NLS_LANGUAGE                   ENGLISH
NLS_TERRITORY                  UNITED KINGDOM
NLS_CURRENCY                   #
NLS_ISO_CURRENCY               UNITED KINGDOM
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               AL32UTF8
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              ENGLISH
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH24.MI.SSXFF
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH24.MI.SSXFF
NLS_TIME_TZ_FORMAT             HH24.MI.SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH24.MI.SSXFF TZR
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_DUAL_CURRENCY              ?
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_RDBMS_VERSION              11.2.0.2.0
20 rows selected.

Check your input script encoding first. If it is not UTF8 you may have issues.
It is important to setup the NLS_LANG when you want to use other encoding in your input than your DB character set.
Your database character set is AL32UTF8, your default linux locale is UTF8 so when you execute an sql command oracle does not translate the characters just simple executes it.
If you setup NLS_LANG oracle automatically translates characters from your input to the database character set accordingly. That's the difference.
So if you did not set the NLS_LANG all characters went into the database as it is because there were no conversion as oracle expected an UTF8 input because that is the default.
Try to get an UTF8 export of your data if that looks good you are good if not you have to fix. I assume you could have issues with specific characters.
Please check your data using Oracle SQL Developer as well.
If you have MOS account see Oracle Support Document 179133.1 [url https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?id=179133.1]The correct NLS_LANG in a Windows Environment and / or
[url https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=264157.1]The correct NLS_LANG setting in Unix Environments Doc ID: 264157.1
for detailed info.

NLS_LANG conversion

Similar Messages

Maybe you are looking for