Character Set Problem with XSQL

Hi!
I am using xsql:insert-request of the xsql-servlet. On NT everything works fine.But on Solaris I get with the same configuration (Oracle 8.1.7 XSQL-Servlet 1.0.4.0) and the same xsl and xsql Files I get the following Error:
Exception 'java.sql.SQLException:Non supported character set: oracle-character-set-46' encountered during processing ROW element 0All prior XML row changes were rolled back. in the XML document.
I want to load Data into an object-relational Table.
Has anyone of you had the same Problem? Has anybody a solution for this Problem. Today I tried different things wihtout any success.
Thanks a lot,
Harald

hi manidhar,
I am also facing the same problem.In my case the characters are getting garbled when it is passed to a javaScript function.
Did u find a solution.
If yes please post it.
thanks in advance

Similar Messages

Character set problem with transportable tablespace

Hi,
I'm trying to import a transportable tablespace with data pump into a database with a different character set compared to the source database. I know this is by default not possible. But there's no violating data in the tablespace that could make it a problem when transfering the TS. So I issued 'ALTER SYSTEM SET "_tts_allow_nchar_mismatch"=true;' on the target to force the import. However; I still get the eror:
ORA-29345: can not plug a tablespace into a database using a different character set
How can I fix this?

Hi,
What're the character sets of the source and target database?
A general restriction of transportable tablespace is that the source and target databases must use the same database character set.
Regards
Nat

Character set problems with xmltype and SQLdeveloper

Hi all,
Using SQL DEveloper v.3.2.20.09 on Windows XP and connecting to Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production.
SQL Developer encoding is set to Cp1252 (my understanding is this has nothing to do with nls_lang and used for encoding of files in sqldeveloper)
SQL Developer NLS Language params set to Canada English.
Database NLS parameters are:
"PARAMETER"    "VALUE"
"NLS_LANGUAGE"    "AMERICAN"
"NLS_TERRITORY"    "AMERICA"
"NLS_CURRENCY"    "$"
"NLS_ISO_CURRENCY"    "AMERICA"
"NLS_NUMERIC_CHARACTERS"    ".,"
"NLS_CHARACTERSET"    "AL32UTF8"
"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.2.0.2.0"
I didn't have an NLS_LANG user env variable set, so i set it to "AMERICAN_AMERICA.WE8MSWIN1252"
Problem i'm having is editing my xmltype data... i have some french accented characters in there, but when saved through SQLDeveloper, they come out as:
Étape par étape -> Ã‰tape par Ã©tape
I do have an encoding on the xml file in the xmltype column set to UTF-8... but from what i read, this has no effect when reading or writing in 11g...
I ran a dump(col, 1016) on my table and got the following:
Typ=58 Len=2037: 0,0,0,1,10,4,8c,a8,0,0,0,1,10,8c,ff,b8,0,0,0,1,11,2,2,f8,0,0,0,1,10,e1,a9,20,3b,9a,ca,0,0,0,f,a0,0,0,f,a0,0,1,0,4,0,0,0,1,9,84,d5,24,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,10,f,93,48,0,0,0,1,10,88,0,8,40,b3,8f,0,0,0,1,41,0,0,0,0,0,0,0,0,0,0,0,1,10,88,ab,b8,0,0,1,40,0,0,0,0,0,0,0,1,10,88,ab,d8,0,0,0,1,10,f,93,48,0,0,40,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,7,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,40,68,6b,78,73,2d,68,65,61,70,2d,63,0,0,0,0,0,0,7f,ff,7f,ff,80,0,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,18,0,0,0,1,10,8d,0,b8,0,0,0,1,10,8d,0,b8,0,0,0,0,0,0,0,28,0,0,0,1,10,8d,0,d0,0,0,0,1,10,8d,0,d0,0,0,0,0,0,0,0,38,0,0,0,1,10,8d,0,e8,0,0,0,1,10,8d,0,e8,0,0,0,0,0,0,0,58,0,0,0,1,10,8d,1,0,0,0,0,1,10,8d,1,0,0,0,0,0,0,0,1,18,0,0,0,1,10,8d,1,18,0,0,0,1,10,8d,1,18,0,0,0,0,0,0,4,18,0,0,0,1,10,8d,1,30,0,0,0,1,10,8d,1,30,0,0,0,0,0,0,10,18,0,0,0,1,10,8d,1,48,0,0,0,1,10,8d,1,48,d0,b3,8f,0,0,0,fe,a9,0,0,0,1,10,8d,0,18,0,0,0,1,10,f,94,e0,0,0,0,1,10,ff,aa,98,0,0,0,1,10,8d,8,98,d0,b3,8f,0,0,0,7,1,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,8,b8,0,0,0,1,10,f,84,48,0,0,0,1,10,8d,8,c0,0,b3,8f,0,0,0,0,31,0,0,0,0,0,0,0,0,0,0,0,1,8,fc,ac,8,d0,b3,8f,0,0,0,fe,41,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,1,10,f,83,a0,0,0,0,1,11,35,a9,0,d0,b3,8f,0,0,0,fe,19,0,0,0,0,0,0,0,0,0,0,0,1,10,f,84,48,0,0,0,1,10,f,84,48,50,0,4,1,0,0,0,18,0,0,0,58,0,4,1,0,0,0,30,0,0,0,60,0,4,1,0,0,0,48,0,0,0,68,0,4,1,0,0,0,60,0,0,0,70,0,4,1,0,0,0,78,0,0,0,78,0,1,1,0,0,0,90,0,0,0,90,0,2,2,0,0,0,a8,0,0,0,a8,0,17,1,1,3,69,2,0,0,0,d0,0,0,0,c0,0,11,1,1,3,69,2,0,0,0,f8,0,0,0,d8,0,20,1,1,3,69,2,0,0,1,20,0,0,1,0,0,14,1,1,3,69,2,0,0,1,48,0,0,1,18,0,40,1,1,3,69,2,0,0,1,70,0,0,1,60,0,28,1,1,3,69,2,0,0,1,98,0,0,1,90,0,3f,1,1,3,69,2,0,0,1,c0,0,0,1,d0,0,1a,1,1,3,69,2,0,0,1,e8,0,0,1,f0,0,28,1,1,3,69,2,0,0,2,10,0,0,2,20,0,2b,1,1,3,69,2,0,0,2,38,0,0,2,50,0,33,1,1,c0,b3,8f,0,0,0,10,81,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,1,10,8d,4d,30,0,0,0,1,10,8d,13,88,d0,b3,8f,0,0,0,10,59,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,13,a8,0,0,0,1,11,0,98,88,0,0,0,1,10,8d,13,c8,0,b3,8f,0,0,0,0,41,0,0,0,0,0,0,0,0,0,0,0,1,8,fc,ac,8,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,3,c0,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,29,0,0,0,1,10,8d,3,40,0,0,0,1,8,fc,ac,50,0,0,0,b7,0,2,43,31,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,99,0,0,0,1,10,8d,3,80,0,0,0,1,9,10,e7,50,1,0,0,0,0,0,0,0,0,0,0,b7,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,0,0,0,7,c7,bf,b8,c0,b3,8f,0,0,0,18,79,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,80,d0,b3,8f,0,0,0,18,51,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,a0,0,0,0,1,10,f,84,48,0,0,0,1,10,8d,1c,a8,10,b3,8f,0,0,0,18,29,0,0,0,0,0,0,0,0,0,0,0,1,8,fb,fe,44,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,68,0,0,0,0,0,0,0,0,0,30,0,30,0,0,0,4,0,0,0,1,10,8d,24,80,0,0,0,1,10,8d,4,88,0,0,0,1,10,8d,4,58,0,0,0,1,10,8d,4,a0,0,0,0,1,10,8d,1c,68,0,0,0,1,10,88,4,f0,0,0,0,1,10,8d,49,38,0,0,0,1,20,0,0,1,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,88,0,0,0,1,9,10,e6,5c,0,0,0,1,10,88,6,0,0,0,0,1,10,8d,38,a0,0,0,0,2,10,8d,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,a8,0,b3,8f,0,0,0,0,69,0,0,0,1,10,88,14,c8,0,0,0,1,10,8d,38,a0,0,0,0,2,20,0,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,c8,0,0,0,0,0,0,0,0,0,0,0,1,10,88,14,30,0,0,0,1,10,8d,38,a0,0,0,0,2,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,e8,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,59,0,0,0,1,10,8d,4,f8,0,0,0,1,8,fd,b9,e0,0,0,0,1,11,0,83,a8,0,0,0,1,11,0,83,a8,0,0,0,1,11,0,83,c0,0,0,0,1,11,0,7b,98,0,0,0,1,10,8d,26,c0,0,0,0,1,10,8d,26,c0,0,0,0,1,8,fd,b9,e0,0,0,8,0,ac,64,61,74,0,b3,8f,0,0,0,4,29,0,0,0,1,10,8d,5,60,0,0,0,1,8,fb,fe,44,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,9,e0,0,0,0,0,0,0,0,0,0,40,0,40,0,0,0,0,0,0,0,1,10,8d,9,f8,0,0,0,1,10,8d,6,0,0,0,0,1,10,8d,5,d0,0,0,0,1,10,8d,6,18,0,0,0,1,10,8d,9,e0,48,45,4d,41,5f,50,52,45,53,45,4e,54,22,23,66,65,35,64,36,61,61,30,35,64,65,62,64,64,65,61,20,23,33,0,0,0,0,0,0,0,2,0,0,4,0,0,0,3,0,0,0,10,44,2,f,a0,1,0,f,d0,41,0,30,d,0,18,d,0,10,0,0,0,0,0,0,3,0,0,0,2,3,80
I find it odd it doesnt tell me what character set is used. If i run a dump 1016 on a varchar2 on the same table, i get:
Typ=1 Len=14 CharacterSet=AL32UTF8: 53,74,65,c3,a9,70,68,61,6e,65,c3,a9,c3,a0
Any ideas? This is frustrating.... xml data gets corrupted everytime it's edited in SQLDeveloper.
Thanks for the help

Thanks for the reply...
create table sample_charset(theString varchar2(2 char), theXml xmltype);
insert into sample_charset values('éà',xmltype('<xml>éà</xml>'));
commit;
select * from sample_charset;
"THESTRING"    "THEXML"
"éà"    <xml>Ã©Ã </xml>
select dump(theString, 1016) as theStringDump, dump(theXml,1016) as theXmlDump from sample_charset;
"THESTRINGDUMP"    "THEXMLDUMP"
"Typ=1 Len=4 CharacterSet=AL32UTF8: c3,a9,c3,a0"
"Typ=58 Len=120: 0,0,0,1,10,4,8c,a8,0,0,0,1,10,e1,a8,60,0,0,0,1,10,dc,36,f8,0,0,0,1,10,95,bf,28,3b,9a,ca,0,0,0,f,a0,0,0,f,a0,0,1,0,4,0,0,0,1,9,84,d5,24,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,10,f,91,28,0,0,0,1,10,db,a8,b8"

Urgent: Character Set Problem with ResultSet

When I use normal statement as below the program works well:
Class.forName("oracle.jdbc.driver.OracleDriver");
String URL = "jdbc:oracle:thin:@10.1.20.8:1521:ora92";
Properties prop = new Properties();
prop.setProperty("user","unistock");
prop.setProperty("password","unistock");
Connection myconn = DriverManager.getConnection(URL, prop);
if (myconn == null) {/ to do:.... }
// in the table, the name, address are defined
// as varchar2(20), and are in the format of
// Chinese characters.
String sql = "select name, address from tbl_node";
Statement mystmt = myconn.createStatement(sql);
ResultSet myresult = mystmt.executeQuery(sql); ......
In such way, I can get the String object of NAME and ADDRESS, which are all Chinese character string.
But when I produce the ResultSet objects that are scrollable in below way it fails to get original string:
//.... the same as before
Statement mystmt = myconn.createStatement(sql,
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet myresult = mystmt.executeQuery(sql); ......
What I get from such way are strings which lost the highest bit information and I can't 'translate' they to the original ones, because maybe they are mixed with Chinese characters and English characters.
What happens when I create the scrollable Statement object? And how can I fix such problem?

hi manidhar,
I am also facing the same problem.In my case the characters are getting garbled when it is passed to a javaScript function.
Did u find a solution.
If yes please post it.
thanks in advance

Character set problem with db link

Hello,
I'm accessing a DB2 database through a database link (ODBC) and I'm getting this error:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[Generic Connectivity Using ODBC]DRV_GetRows: DB_ODBC_ENGINE(1125): ; [IBM][CLI Driver]
[DB2/LINUX] SQLSTATE 01517: A character that could not be converted was replaced with a substitute character
Any help would be appreciated.
Thanks,
Alen

I managed to get around the error with an environment variable.
Here is an extract from the IBM DB2 manual:
For all Windows operating systems, if the DB2CODEPAGE environment variable is not set, the code page is derived from the ANSI code page setting in the Regional Options menu in the Control Panel.
Normally, Windows will not report a Unicode code page in place of the aforementioned ANSI code page. Therefore, a Windows application will typically not behave as a Unicode client. To override this behavior, the DB2CODEPAGE variable can be set to a Unicode code page (1208), which will force the application to behave as a Unicode client.

Using translate function to correct character set problem....

I have a table(TBL_STOCK) on Oracle XE.
Rows come from sql server 2005 with a trigger on sql server table via the linked server.
But there is a character set problem with some character like İ,Ş,Ğ.
They change to Ý,Þ,Ð. in Oracle.
How can i correct these ? Do you suggest the TRANSLATE function ?
What do u think, if i create an After Insert trigger on Oracle table(TBL_STOCK) and convert these character using the Translate function when they inserted from sql server.
Anyone have any other ideas that can be more efficient. Any thoughts appreciated.
Thanks in advance.
Adam
PS:The NLS_CHARACTERSET of Oracle is AL32UTF8.

It is sql server 2005 and Collation is SQL_Latin1_General_CP1_CI_AS

Character problems with xsql:include-xsql reparse="yes"

I have a problem retrieving XML-fragments from CLOB columns.
Danish ISO-8859-1 characters (aelig, oslash, aring) are returned as "?" from Apache/Jserv when using xsql:include-xsql reparse="yes".
My platform is Solaris9/Oracle-9.2.0.2/XDK-9.2.0.4.
Database characterset is we8iso8859p1.
I'm using the Apache/Jserv that comes with Oracle 9.2.0.1.
Steps to reproduce problem:
-- Table data:
create table tab1 (id number,clob_col clob);
insert into tab1 values(1, '<x>fxe</x>');
/*inserted characters are aelig(230), oslash(248), aring(229)*/
commit;
-- test.xsql:
<?xml version="1.0" encoding="ISO-8859-1"?>
<testdata xmlns:xsql="urn:oracle-xsql" connection="pnrtest">
<xsql:include-xsql reparse="yes" href="inc.xsql" />
</testdata>
-- inc.xsql:
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="unquote_clob_col.xsl"?>
<xsql:query
xmlns:xsql="urn:oracle-xsql"
connection="pnrtest"
tag-case="lower"
>
select clob_col
from tab1
</xsql:query>
-- unquote_clob_col.xsl:
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="xml" indent="yes" omit-xml-declaration="no" encoding="ISO-8859-1"/
<xsl:include href="identity.xsl"/>
<xsl:template match="clob_col">
<clob_col>
<xsl:value-of select="." disable-output-escaping="yes"/>
</clob_col>
</xsl:template>
</xsl:stylesheet>
-- identity.xsl:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="node()|@*">

<xsl:copy>

<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
-- Notes:
Running test.xsql works fine with XSQL command-line, but FAILS through Apache/Jserv (danish characters are returned as "?").
inc.xsql works fine through XSQL command-line and Apache/Jserv, problem only happens with xsql:include-xsql reparse="yes" (e.g. test.xsql).
xsql:include-xml works fine, but I cannot use this, bca. in my real business case I'm selecting more than one row from the database.
I've checked and double-checked my jserv.properties several times, and believes it to be correct.
The xsql:include-xsql reparse="yes" technique works fine in our Solaris9/Oracle-8.1.7/iAS-1.0.2.2 environment.
Any suggestions ?
-- Peter ([email protected])

If I put the following line in jserv.properties:
wrapper.env=LANG=en_US.ISO8859-1
the problem with xsql:include-xsql reparse="yes" seems to go away.
Really strange, since Oracle products in my experience normally only uses NLS_LANG, not LANG.
Also, we're accessing several databases with different charactersets from the same ApacheJserv installation, so I don't understand why LANG (or NLS_LANG) should be set to a particular value.
Can anybody explain ?
-- Peter

Backup failure due to Character set problem

Hi,
I am manually running a COLD backup script in Windows NT environment and all the logs has been captured below:
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN-06005: connected to target database: db1 (DBID=754030292)
RMAN-06009: using target database controlfile instead of recovery catalog
RMAN> shutdown immediate;
2> startup mount;
3> RUN {
4> ALLOCATE CHANNEL disk1 TYPE disk;
5> BACKUP DATABASE TAG 'db1_db_full' FORMAT 'e:\backup\db1\db1_backup';
6> copy current controlfile to 'e:\backup\db1\Control_db1.ctl';
7> }
8>
RMAN-06405: database closed
RMAN-06404: database dismounted
RMAN-06402: Oracle instance shut down
RMAN-06193: connected to target database (not started)
RMAN-06196: Oracle instance started
RMAN-06199: database mounted
Total System Global Area 934143244 bytes
Fixed Size 70924 bytes
Variable Size 260554752 bytes
Database Buffers 673439744 bytes
Redo Buffers 77824 bytes
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=13 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: backup
RMAN-06003: ORACLE error from target database: ORA-06550: line 1, column 166:
PLS-00553: character set name is not recognized
ORA-06550: line 0, column 0:
PL/SQL: Compilation unit analysis terminated
RMAN-06031: could not translate database keyword
Recovery Manager complete.
As the above log shown, I cannot do any backup command in the RUN bracket and it complains that the character set is not recognized.
This set of error happens when I have create six other Oracle databases in my NT box. Before that, I can manually run the backup with no problem and a backupset has been generated.
If you have come across this problem and have solutions of it. That will be great.
Thanks !!
null

kk001 wrote:
Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
I don't know what you have.
I don't know what you do.
I don't know what you see.
It is really, Really, REALLY difficult to fix a problem that can not be seen.
use COPY & PASTE so we can see what you do & how Oracle responds.
do as below so we can know complete Oracle version & OS name.
Post via COPY & PASTE complete results of
SELECT * from v$version;

Oracle 8i us7ascii character set problem - help required urgent.

Hi frnds,
I have a oracle 8i database server installed on sun solaris os. The database character set is us7ascii. In one of the tables TIFF images are stored in a long column. I m trying to fetch these images using oracle 9i client and visual basic(oracle ODBC drivers). But i m unable to do so. I can not fetch special characters.
Is it because of the character set problem? but when i run my code on the server itself, i m able to fetch the images. I tried to fetch the images using oracle 8 i client on windows XP machine but could not do so. Are there any special settings that i have to do on the client side?

Indeed, it's an ODBC issue. Read this statement from Oracle:
From ODBC 8.1.7.2.0 drivers onwards it's NOT possible any more to
"disable" Characterset conversion by specifying for the NLS_LANG
the same characterset as the database characterset. There is now
ALWAYS a check to see if a codepoint is valid for that characterset.
Typically you will encounter problems if you upgrade an environment
that has NO NLS_LANG set on the client (or US7ASCII) and the database
was also US7ASCII. This incorrect setup allowed you to store characters
like èçàé in an US7ASCII database, with the new 8i drivers this is not possible
any more.
Basic problem is the 'wrong' characterset US7ASCII in the database. As long as no characterset conversion happens (that's the case on the unix server), special characters are no problem.
Werner

Agent control character set problem

Hi,
here's my problem :
i've got the grid that's running on a RHES4 with an agent. On another RHES4, i've got 10g databases that run and another agent.
The repository database is configured like this :
nsl_language = AMERICAN
nls_territory = AMERICA
character set = AL32UTF8
all the uploads from the agent on the RHES4 where the grid is installed are ok.
On the other server, as soon as there's an UTF8 character in a xml file (like " é " ou " ' "), the upload fails and the agent stops.
in the logs, it s clear it comes from this. I've deleted all the occurences of UTF8 characters in the xml file and restarted the upload and it's ok...
I've tested different configurations but without success.
Any clue ?
Alivetu

Thanks for the reply,
NLS LANG is set on the 2 machines with FRENCHFRANCE.WE8ISO8859P15
I've added the line '<?xml version="1.0" encoding="ISO-8859-1"?>' at the beginning of the xml file that doesn't work and made a 'emctl upload'....it has passed and the agent has stopped arrived to another UTF8 xml file...
So, it really is a character set problem but where to set it ???
Alivetu

Oracle character set problem - help reqed urgent !!

Hello frnds,
I have a oracle 8i database server installed on sun solaris os. The database character set is us7ascii. In one of the tables TIFF images are stored in a long column. I m trying to fetch these images using oracle 9i client and visual basic(oracle ODBC drivers). But i m unable to do so. I can not fetch special characters.
Is it because of the character set problem? but when i run my code on the server itself, i m able to fetch the images. I tried to fetch the images using oracle 8 i client on windows XP machine but could not do so. Are there any special settings that i have to do on the client side?

i run my code on the server itself, i m able to fetch
the images. I tried to fetch the images using oracle
8 i client on windows XP machine but could not do so.You able to fetch the image , So it is not because of the character set.
First thing you need to consider is that use certified combination of OS , client and database server only. Check Certify - Oracle's Certification Matrices
Virag

EXPORT Backup failing due to character set problem

Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
Regards,
kk
Edited by: kk001 on Aug 29, 2011 7:22 PM

kk001 wrote:
Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
I don't know what you have.
I don't know what you do.
I don't know what you see.
It is really, Really, REALLY difficult to fix a problem that can not be seen.
use COPY & PASTE so we can see what you do & how Oracle responds.
do as below so we can know complete Oracle version & OS name.
Post via COPY & PASTE complete results of
SELECT * from v$version;

Problems with LPX-00245 (character set problem?)

Hi all,
I've got a problam with ORA-19202 and LPX-00245 (extra data after end of document) when querying my xmltype table. The table contains one large xml document. This xml document is valid, I've checked it against the corresponding XSD (using JDeveloper and also Notepad++, no validation errors).
I gues it has something to do with the encoding of the document. The original encoding is ISO-8859-1 (<?xml version="1.0" encoding="ISO-8859-1"?>). When I load the document to the database it is autoamtically changed to UTF-8 (<?xml version="1.0" encoding="UTF-8"?>) maybe because the character setting of my database is AL32UTF8.
I use the following statement to store my XML:
      insert into my_table
      values( my_seq_spp.nextval,
           r_get_files.file_name,
              xmltype(
              bfilename(p_directory, r_get_files.file_name) -- p_directory is the name of an oracle dircetory
              , nls_charset_id('WE8ISO8859P1')
Nevertheless the retrieved charset id 31 is ignored. Also if II use csid = 0, it doesn't work...
Any idea how to enforce using ISO-8859-1 instead UTF-8 as character set?
Best regards
Matthias

Hi Marco,
I don't think it has anything to do with encoding (client-side or not).
I'd be more inclined to say it's related to XML fragments manipulation.
@Matthias :
Does this work better :
select m.version
     , sp.Betriebsstelle
     , spa.Betriebsstellenfahrwege
from imp_spurplan t
   , xmltable('/XmlIssDaten'
       passing t.xml_document
       COLUMNS
         Version                  varchar2(6) path 'Version/Name'
       , Spurplanbetriebsstellen xmltype     path 'Spurplanbetriebsstellen'
     ) m
   , xmltable('/Spurplanbetriebsstellen/Spurplanbetriebsstelle'
       passing m.Spurplanbetriebsstellen
       COLUMNS
         Betriebsstellenfahrwege_xml xmltype      path 'Betriebsstellenfahrwege'
       , Betriebsstelle              varchar2(6) path 'Betriebsstelle'
     ) sp
   , xmltable('/Betriebsstellenfahrwege'
       passing sp.Betriebsstellenfahrwege_xml
       COLUMNS
         Betriebsstellenfahrwege xmltype path '.'
     ) spa
where sp.Betriebsstelle = 'NWH'

DIR7 Character Set Problem / Foreign Language

Hi there,
I am working on an app built using Director 7 that until now
has used the standard English (latin-1) character set.
However, I am required to deliver a new version including
some elements displayed in a second language, in this case Welsh,
which uses characters outside of the normal set. I believe those
required are included in Latin-1 Extended, otherwise in Unicode as
a whole, obviously.
I am having specific problems with two characters that appear
to be missing from Latin-1, which are: ŵ and ŷ
(w-circumflex, and y-circumflex [i think!]).
In a standard text box I create using Director, I am unable
either to paste either character in, or enter it using its
ALT+combination, let alone save to the associated database.
I have read that Dir 11 is the first version with full
Unicode support - which surprises me - however I would assume that
someone would likely have hit this, or a similar issue before the
release of this version and was wondering if there is a possible
solution without upgrade.
My possible thinking is either a declaration that allows
change of a Charset, as I might do in XHTML for example, or
deployment of an Xtra that allows me to use a different character
set.
If anyone could shed some light on the matter, it would be
very helpful! Thanks in advance!
Rich.

Yes, this was always a problem for years. Back when I was
**** this, we had
some projects that needed text displayed in various
languages. Each
language presented its own challenges. Things like Greek
weren't too bad,
because the Symbol font works for most Greek text. (Only
problem was the
's' version of Sigma, which had to switch back to Times New
Roman.) Various
eastern European languages (Polish, Czech, Hungarian, etc.)
posed a problem
with some of the accents that were not available in standard
font sets. We
were forced to live without some of the more exotic accents,
but were told
that it would still be readable without them, if not exactly
correct. This
would probably be the closest to your situation, from what
little I know
about Welsh. It could be worse, though. Hebrew and Arabic
were challenging
as they are written right-to-left, and thus had to have code
written to
input them backwards. Russian was also tough, as the Cyrillic
alphabet has
more characters than the others, but I was able to find a
font to fake it.
(It replaced some of the lesser-used standard characters in
order to fill in
all the letters, which unfortunately meant that in the rare
cases where
those characters *were* needed, we had to improvise.) The
hardest by far
were any east Asian languages. In that case, I gave up on
trying to display
any of the text in text form, and just converted it all to
bitmaps. Without
Unicode, trying to display Mandarin or Japanese or Korean
correctly as text
is pretty much impossible.

Character Setting Problem ( mysql + tomcat )

Hi all;
I am using mysql dbms and tomcat web server(servlet). But in my web page, the characters are shown broken. I set the character set of the mysql database. They are shown well in the dbms console. And also I set the html code with appropriate character set in the meta tags. Do I need to make any extra setting? Perhaps in the tomcat or anywhere else? What is the problem here?

assumes:
1. using jsp to display the db data
2. db encoding is ISO-8859-1
3. jsp encoding is utf-8
for the very first line of the jsp file:
<%@ page pageEncoding="utf-8" %>before displaying the data:
String str = <data from db>
str = new String(str.getBytes("ISO-8859-1"), "UTF-8");

Character Set Problem with XSQL

Similar Messages

Maybe you are looking for