FailUTF8Conv

I' ve got the following runtime error on a JSP-based
application:
Konvertierung zwischen UTF8 und UCS2 nicht erfolgreich: failUTF8Conv
(conversion between UTF8 and UCS2 not successfull:
failUTF8Conv)
I use the jdbc:thin driver for Release 9.2.0.1
The error appears during try to load records with
german specific characters
like ß, ü , ä etc.
This records were imported from an oracle 8.1.7 instance
via flat-files using SQL_Loader.
Can anybody help ?

I don't know much about the topic in question, but in general, you'll stand a better chance of getting help if you provide more details.
What does your code look like? What's are the characters in question? What's the complete stack trace? etc. etc.

Similar Messages

Fail to convert between UTF8 and UCS2: failUTF8Conv

We need to store possibly all UTF8 chararacter in his database
especially $ & ( 4 8 < = > from WE8ISO8859P1 and from WE8ISO8859P15.
So we install an UTF8 instance and set NLS_LANG to UTF8.
We have to do select/update from a java client and sqlplus(like).
When we insert with java client it's unreadable from sqlplus and
when whe insert from sqlplus we've got 'Fail to convert between UTF8 and UCS2: failUTF8Conv '
here the code made in sqlplus
update CPW_TEST set lb_comportement='$ & ( 4 8 < = > ' WHERE ID_TEST=14805;
here the code made in java
update CPW_TEST set lb_comportement='$ & ( 4 8 < = > ' WHERE ID_TEST=14804;
and then the result in database
SELECT id_test,LB_COMPORTEMENT FROM CPW_TEST WHERE ID_TEST=14804 or ID_TEST=14805
ID_TEST LB_COMPORTEMENT
14804 B$ B& B( B4 B8 B< B= B> B
14805 $ & ( 4 8 < = >
2 rows selected
and the dump
SELECT id_test,dump(LB_COMPORTEMENT) FROM CPW_TEST WHERE ID_TEST=14804 or ID_TEST=14805
ID_TEST DUMP(LB_COMPORTEMENT)
14804 Typ=1 Len=26: 194,164,32,194,166,32,194,168,32,194,180,32,194,184,32,194,188,32,194,189,32,194,190,32,194,128
14805 Typ=1 Len=17: 164,32,166,32,168,32,180,32,184,32,188,32,189,32,190,32,128
2 rows selected
I'm not sure, but it seems that sqlplus uses true UTF8 (variable length codes) and java client uses UCS-2 (2 bytes)
How can I solve my problem?
Our configuration
javaclient (both thin and oci jdbc driver 8.1.7), sqlplus client and database Oracle 8.1.7.0.0 on the same computer (W2000 or NT4)
Thank you for yoru attention.

Hi Luis, thanks for your suggestions. You're right that problem was in JServ and his JVM.
There was conflict between different versions of Java. While iFS was using JRE 1.3.1, JServ was configured to use JRE 1.1.8. As soon as I corrected link to the right Java, problem disappears.
Radek

Java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv

Hi all,
I am writing a servlet that connects to Oracle 8.0.6 through jdbc for jdk1.2 on NT 4.0
English version and it works fine.
But when the servlet is deployed to a solaris with Oracle 8.0.5 (not a typo, the oracle on
NT is 8.0.6 and oracle on solaris is 8.0.5) and jdbc for jdk1.2 (of course, for Solaris),
the servlet failed with the Exception:
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
(I am using JRun 3.0 as the application and web server for both NT and Solaris)
(The database in both the NT and solaris platform are using UTF8 charset)
My servlet looks like this: (dbConn is a Connection object proved to be connected to Oracle
in previous segment of the same method):
String strSQL = "SELECT * FROM test";
try { Statement stmt = dbConn.createStatement();
ResultSet rs = stmt.execute(strSQL);
while (rs.next()) {
out.println("id = " + rs.getInt("id"));
System.out.println("id written");
out.println("name = " + rs.getString("name")); // <-- this is the line the
exception is thrown
System.out.println("name written");
} catch (java.sql.SQLException e) {
System.out.println("SQL Exception");
System.out.println(e);
The definition of the "test" table is:
create table test(
id number(10,0),
name varchar2(30));
There are about 10 rows exists in the table "test", in which all rows contains ONLY chinese
characters in the "name" field.
And when I view the System log, the string "id written" is shown EXACTLY ONCE and then there
is:
SQL Exception
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
That means the resultset is fetch back from the database correctly. The problem arise only
during the getString("name") method.
Again, this problem only happens when the servlet is run on the solaris platform.
At first I would expect there are some strange code shown on the web page rather than having
an exception. I know that I should use getBytes to convert between different encodings, but
that's another story.
One more piece of information: When all the rows contains ascii characters in their "name"
field, the servlet works perfectly even in solaris.
If anyone knows why and how to tackle the problem please let me know. You can feel free to
send email to me at [email protected]
Many thanks,
Ben
null

Hi all,
For the problem I previously posted, I found that Oracle had had such bug filed before in Oracle 7.3.2 (something like that) and is classified to be NOT A BUG.
A further research leads me to the document of Oracle that the error message:
"java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv"
is a JDBC driver error message of error number ORA-17037.
I'm still wondering why this behaviour will happen only in Solaris platform. The servlet on an NT machine I am using (which has an Oracle 8.0.6 and jdbc for jdk 1.2 running) is working just fine. I also suspect that this may be some sort of mistakes from jdbc driver.
Nevertheless, I have found a way to work around the problem that I cannot get non-English string from Oracle in Solaris and I would like to share it with you all here.
Before I go on, I found that there are many people out there on the web that encounter the same problem. (Some of which said s/he has been working on this problem for a month). As a result, if you find this way of working around the problem does help you, please tell those who have the same problem but don't know how to tackle. Thanks very much.
Here's the way I work it out. It's kinda simple, but it does work:
Instead of using:
String abc = rs.getString("SomeColumnContainsNonEnglishCharacters");
I used this:
String abc = new String(rs.getBytes("SomeColumnContainsNonEnglishCharacters"));
This will give you a string WITH YOUR DEFAULT CHARSET (or ENCODING) from your system.
If you want to convert the string read to some other encoding type, say Big5, you can do it like this:
String abc = new String(rs.getBytes("SomeColumneContainsNonEnglishCharacters"), "BIG5");
Again, it's simple, but it works.
Finally, if anyone knows why the fail to convert problem happens, please kindly let me know by leaving a word in [email protected]
Again, thanks to those of you who had tried to help me out.
Creambun
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by creambun creambun ([email protected]):
Hi all,
I am writing a servlet that connects to Oracle 8.0.6 through jdbc for jdk1.2 on NT 4.0
English version and it works fine.
But when the servlet is deployed to a solaris with Oracle 8.0.5 (not a typo, the oracle on
NT is 8.0.6 and oracle on solaris is 8.0.5) and jdbc for jdk1.2 (of course, for Solaris),
the servlet failed with the Exception:
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
(I am using JRun 3.0 as the application and web server for both NT and Solaris)
(The database in both the NT and solaris platform are using UTF8 charset)
My servlet looks like this: (dbConn is a Connection object proved to be connected to Oracle
in previous segment of the same method):
String strSQL = "SELECT * FROM test";
try { Statement stmt = dbConn.createStatement();
ResultSet rs = stmt.execute(strSQL);
while (rs.next()) {
out.println("id = " + rs.getInt("id"));
System.out.println("id written");
out.println("name = " + rs.getString("name")); // <-- this is the line the
exception is thrown
System.out.println("name written");
} catch (java.sql.SQLException e) {
System.out.println("SQL Exception");
System.out.println(e);
The definition of the "test" table is:
create table test(
id number(10,0),
name varchar2(30));
There are about 10 rows exists in the table "test", in which all rows contains ONLY chinese
characters in the "name" field.
And when I view the System log, the string "id written" is shown EXACTLY ONCE and then there
is:
SQL Exception
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
That means the resultset is fetch back from the database correctly. The problem arise only
during the getString("name") method.
Again, this problem only happens when the servlet is run on the solaris platform.
At first I would expect there are some strange code shown on the web page rather than having
an exception. I know that I should use getBytes to convert between different encodings, but
that's another story.
One more piece of information: When all the rows contains ascii characters in their "name"
field, the servlet works perfectly even in solaris.
If anyone knows why and how to tackle the problem please let me know. You can feel free to
send email to me at [email protected]
Many thanks,
Ben<HR></BLOCKQUOTE>
null

JDBC thin driver, failUTF8Conv

I browse through JDBC some records from an Oracle 8.1.7 DB with NLS_CHARACTER=EL8ISO8859P7 and greek data.
Some records (columns are type varchar2) are displayed ok, but at some other certain records, an exception occurs and I get:
"JBO-27022: Failed to load value at index 3 with java object of type java.lang.String due to java.sql.SQLException.
Error Message: Fail to convert between UTF8 and UCS2:failUTF8Conv"
How can this be solved?
(Oracle 8.1.7 on linux, Oracle JDBC thin driver)

See posting in Oracle java help.

FailUTF8Conv problem !

Hi,
I am getting this exception while getting records from the oracle database.
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
Is there anyone know that how can resolve this problem ?
thanks in advance,
bregoty

I don't know much about the topic in question, but in general, you'll stand a better chance of getting help if you provide more details.
What does your code look like? What's are the characters in question? What's the complete stack trace? etc. etc.

SQL Exception: Fail to convert between UTF8 and UCS2: failUTF8Conv

Hi,
I am trying to use the DBMS_OBFUSCATION_TOOLKIT to encrypt/decrypt some strings through JDBC, but I am getting the following exception:
SQL Exception: Fail to convert between UTF8 and UCS2: failUTF8Conv
The input and output parameters for the encryption/decryption functions are VarChar2.
Our database is using UTF8.
I will be glad if someone can help me on this.
Thanks,
Cenk

Susi,
This is just a wild guess, but your java client is on a different computer to your Oracle 9.2 server, and the locale (or encodings) on the two computers is different. Am I correct? If so, then I guess you need to change the locales (or encodings) so that they match.
Have you tried printing out the "System" properties for the two JVMs (Oracle's and your client's)? Something simple like this:
System.getProperties().list()Good Luck,
Avi.

JBO-27022, Fail to convert between UTF8 and UCS2: failUTF8Conv

steps to reproduce :
on a Database with UTF8 as NLS_CHARACTERSET
create table test (s1 varchar2(10), s2 varchar2(32));
DECLARE
l_data varchar2(4000);
return_data varchar2(4000);
skey varchar2(255);
p_str varchar2(10);
BEGIN
p_str := 'Test';
skey := chr(20) || chr(115) || chr(110) || chr(122) || chr(37) || chr(37) || chr(94) || chr(48);
l_data := rpad (p_str,(trunc(length(p_str)/8)+1)*8, chr(0));
dbms_obfuscation_toolkit.DESEncrypt (input_string=>l_data, key_string =>skey,
encrypted_string => return_data);
insert into test values ('1',return_data);
END;
commit;
Now create a new Workspace and a new "Business Components Package"
with only table test selected.
In the tester we get an oracle.jbo.AttributeLoadException:
(oracle.jbo.AttributeLoadException) JBO-27022: Failed to load value at index 2
with java object of type java.lang.String due to java.sql.SQLException.
----- LEVEL 1: DETAIL 0 -----
(java.sql.SQLException) Fail to convert between UTF8 and UCS2: failUTF8Conv
oracle.jbo.AttributeLoadException: JBO-27022: Failed to load value at index 2 with java object of type java.lang.String due to java.sq[i]Long postings are being truncated to ~1 kB at this time.

This is still happening in jdev9031.
And it is very easy to reproduce!
How can we avoid this error?
Thanks,
Bert.

Help me,Fail to convert between UTF8 and UCS2: failUTF8Conv

using SUN APP server 7.0 + Studio 4 +oracle9i to develop cmp, when i input chinese in some fields, i encount following errors:
java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180)
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:222)
at oracle.jdbc.dbaccess.DBError.check_error(DBError.java:916)
at oracle.jdbc.dbaccess.DBConversion.failUTF8Conv(DBConversion.java:1958)
at oracle.jdbc.dbaccess.DBConversion.utf8BytesToJavaChars(DBConversion.java:1797)
at oracle.jdbc.dbaccess.DBConversion.charBytesToJavaChars(DBConversion.java:828)
at oracle.jdbc.dbaccess.DBConversion.CHARBytesToJavaChars(DBConversion.java:783)
at oracle.jdbc.ttc7.TTCItem.getChars(TTCItem.java:231)
at oracle.jdbc.dbaccess.DBDataSetImpl.getCharsItem(DBDataSetImpl.java:1094)
at oracle.jdbc.driver.OracleStatement.getCharsInternal(OracleStatement.java:2947)
at oracle.jdbc.driver.OracleStatement.getStringValue(OracleStatement.java:3103)
at oracle.jdbc.driver.OracleStatement.getObjectValue(OracleStatement.java:5089)
at oracle.jdbc.driver.OracleStatement.getObjectValue(OracleStatement.java:4964)
at oracle.jdbc.driver.OracleResultSetImpl.getObject(OracleResultSetImpl.java:404)
at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.getConvertedObject(ResultDesc.java:399)
at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.setFields(ResultDesc.java:746)
at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.getResult(ResultDesc.java:635)
at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:648)
at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:500)
at com.sun.jdo.spi.persistence.support.sqlstore.SQLStateManager.reload(SQLStateManager.java:1197)
at com.sun.jdo.spi.persistence.support.sqlstore.SQLStateManager.loadForRead(SQLStateManager.java:3797)
at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:604)
at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerWrapper.getObjectById(PersistenceManagerWrapper.java:247)
at com.tops.gdgpc.EntityBean.SpeBaseTable.SpeBaseTableBean_1769729755_ConcreteImpl.jdoGetInstance(SpeBaseTableBean_1769729755_ConcreteImpl.java:2479)
at com.tops.gdgpc.EntityBean.SpeBaseTable.SpeBaseTableBean_1769729755_ConcreteImpl.ejbLoad(SpeBaseTableBean_1769729755_ConcreteImpl.java:2267)
at com.sun.ejb.containers.EntityContainer.callEJBLoad(EntityContainer.java:2372)
at com.sun.ejb.containers.EntityContainer.afterBegin(EntityContainer.java:1362)
at com.sun.ejb.containers.BaseContainer.startNewTx(BaseContainer.java:1405)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:1313)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:462)
at com.tops.gdgpc.EntityBean.SpeBaseTable.SpeBaseTableBean_1769729755_ConcreteImpl_EJBObjectImpl.getSpeBaseTable(SpeBaseTableBean_1769729755_ConcreteImpl_EJBObjectImpl.java:24)
at com.tops.gdgpc.EntityBean.SpeBaseTable._SpeBaseTable_Stub.getSpeBaseTable(Unknown Source)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.forte4j.j2ee.ejbtest.webtest.InvocableMethod$MethodIM.invoke(InvocableMethod.java:233)
at com.sun.forte4j.j2ee.ejbtest.webtest.EjbInvoker.getInvocationResults(EjbInvoker.java:98)
at com.sun.forte4j.j2ee.ejbtest.webtest.DispatchHelper.getForward(DispatchHelper.java:191)
at jasper.dispatch_jsp._jspService(_dispatch_jsp.java:127)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
at javax.servlet.http.HttpServle
I think it is caused by that the fields' not enought long.UTF must use 3 characters for one chinese,but in our database only 2 characters for one chinese.How can I resolve this puzzle,please help me!

I've got many more tips from our experts:
1. One thing you can try to do is make sure that Oracle Databse is set to UTF-8. If this is the case then you need to make sure that the client encoding is UTF-8.
2. A colleague at Oracle points out that oracle.jdbc.* is a package that Oracle
provides, not Sun. He says you might try asking this question on an Oracle
forum. He writes:
We have Oracle Technology Network (OTN) discussion forum, which would be a good place to
start with this question.
Oracle Technology Network (OTN) " Technologies " Java " SQLJ/JDBC
Try the SQLJ/JDBC forum first.
-- markus.

Failed to convert between UTF8 and UCS2: failUTF8Conv

This error appear when trying to install the database cache. Does this have something to do with the classes111.zip or classes12.zip files?

I have the same problem in XP. I installed the whole Oracle9i product on my desktop and after a day or two the message began appearing on my machine. I couldnt use any of the tools. I tried uninstallinmg according to Oracles instruction and after installing again had the same problem.
I logged a TAR and they advised me to reinstall but according to Oracles instructions for removing the software first.
Will keep you posted

Insert Unicode Characters Into Oracle 8.1.5

Hello,
First off, here are the specs:
Oracle 8.1.5
JDK 1.2.1
Oracle8i 8.1.6.2.0 JDBC Drivers for use with JDK 1.2.x for Solaris
I'm running into a problem with insert Unicode characters into Oracle via the JDBC driver. As you can see above, I am using the Oracle 8.1.6.2.0 JDBC driver because it is the first driver with supports the JDK 1.2.x. So I think I should be okay.
I can retrieve data with special characters from Oracle by calling the getBytes() method from the ResultSet with all special characters being intact. I am using getBytes because calling getString() would throw the following exception: "java.sql.SQLException(): Fail to convert between UTF8 and UCS2: failUTF8Conv". However, with that value that I just retrieved, or any other data with special characters (unicode) in which I try to insert into Oracle does not get converted properly.
What appears to be happening is that data with special characters (unicode), are not being treated as a single double byte character, but rather two single byte characters. Thus, R|ckschlagventil becomes RC<ckschlagventil once it is inserted. (Hopefully, my example will be rendered properly).
According to all documentation that I have found, the JDBC driver should not have any problem with converting UCS2 Java Strings to Oracle's UTF8 character set.
I have set Oracle's NLS_NCHAR_CHARACTERSET to UTF8. I am also setting the environment variable NLS_LANG to AMERICAN_AMERICA.UTF8. Perhaps there is some other environment setting in which I am missing?
Any help would be appreciated,
Christian
null

Import has a lot of options, so it depends on what you want to do.
C:\> imp help=y
will show you all possible options. An example of full import :
C:\> imp <username>/<password>@<TNS alias> file=<DMP file> full=y log=<LOG file>
Message was edited by:
Paul M.
...and there is always [url http://download-uk.oracle.com/docs/cd/F49540_01/DOC/index.htm]The documentation

Problem in Database convertion from US7ASCII to UTF8

Hi,
We are facing the following problem while converting the database from US7ASCII to UTF8:
We have recently changed the database character set from US7ASCII to UTF8 for the internationalization
purpose. We ran the Character set scanner utility and it did report that some data may pose problems.
We followed the the below mentioned process to convert into UTF8 -
1) alter database character set utf8
2) alter database national character set utf8.
Now we find some problem while working with the old data in our application which is java based.
We are getting the following error "java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv".
We further analyzed our data and found some interesting things :
e.g.
DB - UTF8.
NL_LANG also set to UTF8.
Select name from t1 where name like 'Gen%';
NAME
Genhve
But when we find out the length of the same data it show like this
NAME LENGTH(NAME) VSIZE(NAME)
Genhve 4 6
The question is why is it showing length as 4 only and when we try to use a substr function
its extracting like the following :-
select name,substr(name,4,1) from t1 where name like 'Gen%';
NAME SUB
Genhve hve
We have execute the above queries on US7ASCII DB and it is working fine, length it shows 6
and using SUBSTR it extracts just 'h' as well.
We also used dump function on the UTF8 Db for the above query,,this is the result :-
select name,length(name),vsize(name),dump(name) from t1 where name like 'Gen%';
NAME LENGTH(NAME) VSIZE(NAME) DUMP(NAME)
Genhve 4 6 Typ=1 Len=6: 71,101,110,232,118,101
We checked a lot with the data and it seems 'h' (accented e) is posing the problem.
We want to know where is the problem and how to overcome this.
Further, we tried all of the following :
1)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute e became h
2)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: IMP 00016 error
3)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute E became h
4)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: Acute e became h
5)
Tried using Update sys.props$
set value$='UTF8'
where name='NLS_CHARACTERSET'
RESULT: Acute e shows properly but it gives problem in the application
"java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv"
Looking further it was observed the following:
when you try this command on a column 'city' in a table which contains 'Genhva' (note the acute e after n), it shows
command: select length(city), vsize(city),substr(city,4,1),city from cities
Result: 4 6 hva Genhva
if you see the value of substr(city,4,1) , you will see the problem. Also note that the length shows 4 and size shows 6. Moreover, when these records are selected through JDBC Driver, it starts giving problems.
6)
Actually the above (point no. 5) is similar to changing the character set of the database with 'ALTER DATABASE CHARACTER SET UTF8'. Same problem is observed then too.
7)
We have also tried to with another method, that is by changing the third byte of the export file which specifies the character set, to the UTF8 code by editing the export file with a Hexdecimal editor. After import the same problem has been observed as defined in (5) and (6) above.
We have no more ideas how to migrate without corrupting the data. Of course we have known the records where these characters occur through the Oracle's cssacn utility but we do not want to manually rectify each and every record by replacing it with an ASCII character. Any other idea as to how this can be accomplised?
Thanx
Ashok

The problem you have is that although your original database is defined as US7ASCII, the data it contains is more than is covered by this code page (as the reply on Sept 4 to the previous posting already said).
This has probably happened because the client was also defined as US7ASCII, and when the DB and client are defined as having the same character set no conversion (or checdking) takes place when data is passed between them. However if you are using a Windows client then it will in fact be using Windows code page 1252 (Latin-1) or similar, and this allows many more characters, including h (accented e). So a user can enter all these characters and store them in the database, and similarly read them from the database, because data transfer is transparent.
When you did ALTER DATABASE CHARACTER SET UTF8 this will only change the label on the database, but not affect the contents. However only part of the contents are valid UTF8, any character above 7F (like h) is invalid. If your original client now uses the database, code page transformation will take place because the client and DB have different character sets defined. The invalid codes can then cause problems.
Without being able to explain what has happened in detail, it may help to see what your h (dec 232, x'E8') looks like. The actual data has not changed (you can see this as it is reported as 232). However the binary code there (11101000) is invalid UTF8. UTF8 encodes a character in 1 to 4 bytes, and the first bits in a UTF8 character tell how many bytes it uses. 0xxx tell it is one byte (same as the corresponding USASCII character), 110x that it uses 2 bytes, 1110 that it uses 3 bytes etc. So if you interpret what is there as UTF8 it looks like the first byte of a 3-byte character, which explains why the substringing is giving you the other 2 bytes as well.
Can you fix this without losing data? I believe yes. First you should check what other characters are being flagged by the scan. See if these are contained in another standard character set. If they are only Western European accentet characters then WE8ISO8859P1 is probably ok, but watch out for the euro sign which Windows has at x'80', an undefined character in ISO8859-1.
You can see the contents of the Microsoft Windows Codepage 1252 at: http://www.microsoft.com/globaldev/reference/sbcs/1252.htm
For a listing of the US-ASCII defined characters see http://czyborra.com/charsets/iso646.html and for ISO 8859-1 see http://czyborra.com/charsets/iso8859.html#ISO-8859-1
If all is well, you can first ALTER DATABASE CHARACTER SET to WE8ISO8859P1. This will not change any data, but ensure that all the data gets exported. Then export the DB and import it to a UTF8 DB. This will convert the non-US-ASCII characters to Unicode. You will also have to change the clients character set to something other than USASCII or they will just see ? for the other characters.
Good Luck!

Fail to convert between UTF8 and UCS2

: java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
(BC4J throws that exception)
I got that error message when try to show the table's content in uix page.
I use varchar2(40). the error occurs, when i set special characters like õ,ü,Ü.. and so on.
This affects only UTF encoded database.
We use: 9.0.2.5, Jdev9.0.3.3., UIX, iAS 9.4.2??(i dont'know)
As i know the problem is when there is 40 letters in the column and it contains "special character" it can't convert it, because the neccessary space requered to store values is much more.
If i use nvarchar, i don't think it fix this problem.
And as i know, all sql constant must use where coulmn=N'constans value' format.
Q:
How can i set the UTF database and BC4J to run correctly.
I mean... what type to use, what is the column size to set.
Thanks in advice,
Viktor

I had the same problem using Oracle 9i. The problem lied within the Oracle JDBC driver itself! --;
If you're using JDBC driver from Oracle 9i, stop using it!
You should download JDBC driver of Oracle 10g from Oracle site and use that driver instead.
After I changed the driver, I now have no problem of getting Korean characters from the database.
Hope this would solve your problem too.

Problems with Accented Characters after migrating to UTF8

Hi,
I am puzzled about the following problem.
We have recently changed the database character set from US7ASCII to UTF8 for the internationalization
purpose. We ran the Character set scanner utility and it did report that some data may pose problems.
We followed the the below mentioned process to convert into UTF8 -
1) alter database character set utf8
2) alter database national character set utf8.
Now we find some problem while working with the old data in our application which is java based.
We are getting the following error "java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv".
We further analyzed our data and found some interesting things :
e.g.
DB - UTF8.
NL_LANG also set to UTF8.
Select name from t1 where name like 'Gen%';
NAME
Genhve
But when we find out the length of the same data it show like this
NAME          LENGTH(NAME)          VSIZE(NAME)
Genhve 4 6
My question is why is it showing length as 4 only and when we try to use a substr function
its extracting like the following :-
select name,substr(name,4,1) from t1 where name like 'Gen%';
NAME               SUB
Genhve          hve
We have execute the above queries on US7ASCII DB and it is working fine, length it shows 6
and using SUBSTR it extracts just 'h' as well.
I also used dump function on the UTF8 Db for the above query,,this is the result :-
select name,length(name),vsize(name),dump(name) from t1 where name like 'Gen%';
NAME          LENGTH(NAME)          VSIZE(NAME)               DUMP(NAME)
Genhve 4 6               Typ=1 Len=6: 71,101,110,232,118,101
I checked a lot with the data and it seems 'h' (accented e) is posing the problem.
I want to know where is the problem and how to overcome this.
Regards
Siba

We ran the Character set scanner utility and it did report that some data may pose problems. Did you check out the documentation with the scanner ? It explains why and how to deal with problem data.
The problems are :-
1. You had invalid data inside your original US7ASCII database . h is not a valid 7 bit ASCII character. All the invalid US7ASCII characters, ( ie. all those that will be lost after doing ALTER DATABASE CHARACTER SET ) would have been flagged by the scanner.
2. All non 7 bit ASCII characters need to be converted to their UTF8 counterpart values, and typically these characters will have size expansions too. for example ,from 1 byte to 2 bytes.
3. ALTER DATABASE CHARACTER SET UTF8 changes the character set tag in the database header only. No data conversions are performed to your existing data .
Hi,
I am puzzled about the following problem.
We have recently changed the database character set from US7ASCII to UTF8 for the internationalization
purpose. We ran the Character set scanner utility and it did report that some data may pose problems.
We followed the the below mentioned process to convert into UTF8 -
1) alter database character set utf8
2) alter database national character set utf8.
Now we find some problem while working with the old data in our application which is java based.
We are getting the following error "java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv".
We further analyzed our data and found some interesting things :
e.g.
DB - UTF8.
NL_LANG also set to UTF8.
Select name from t1 where name like 'Gen%';
NAME
Genhve
But when we find out the length of the same data it show like this
NAME          LENGTH(NAME)          VSIZE(NAME)
Genhve 4 6
My question is why is it showing length as 4 only and when we try to use a substr function
its extracting like the following :-
select name,substr(name,4,1) from t1 where name like 'Gen%';
NAME               SUB
Genhve          hve
We have execute the above queries on US7ASCII DB and it is working fine, length it shows 6
and using SUBSTR it extracts just 'h' as well.
I also used dump function on the UTF8 Db for the above query,,this is the result :-
select name,length(name),vsize(name),dump(name) from t1 where name like 'Gen%';
NAME          LENGTH(NAME)          VSIZE(NAME)               DUMP(NAME)
Genhve 4 6               Typ=1 Len=6: 71,101,110,232,118,101
I checked a lot with the data and it seems 'h' (accented e) is posing the problem.
I want to know where is the problem and how to overcome this.
Regards
Siba

JDBC drivers not working in QA for multibye characters

Hi,
we have a problem with JDBC and deployed in DEV system and its works fine, but the same when we deply in QA its not working.
the problem we are trying to use the simple select query from ORACLE DB.
In ORACLE DB they converted the chenise char to English after that our JDBC drivers are not able to pick the multibite char.
XI JDBC Adapter shows below error with a SELECT Query
SELECT Query:SELECT * FROM APPS.ITEM_XI_V The Chinese character are converted to English and becomes multibye characters.
Error:Error during conversion of query result to XML: java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv
Assumption is that the issue with older version of ojdbc14.zip (JDBC Driver file)
Reference:http://www.coderanch.com/t/299231/JDBC/java/UTF-conversion
implement SAP Note 941317 in order to resolve the current issue.
Note 941317 - XI / PI JDBC Adapter: Known Problems / Incompatibilities JDBC Driver Deployment. Refer to SAP Note 831162
after apply as per note for DEV system its works fine, but the same when we did for our QA system still the same error.
Thanks,
Venkat.

Hi Gurus,
Any idea where i am doing wrong.. in QA i am able to extract data with simple select statment with normal tables...
Thanks,
Venkat

Read japanese char from oracle

I have a database column stores japanese char in Shift-JIS encoding. A
perl script can read the database and display the result on browser.
But If i try the get the japanese string in Java using JDBC. I got an
exception:
String text = resultset.getString(1);
Exception in main(): java.sql.SQLException: Fail to convert between
UTF8 and UCS2: failUTF8Conv
I wonder why I getting this exception and how to fix this?
thanks

Hi
We had faced the same problem.
Problem was with oracle jdbc thin driver.
We change the driver from THIN to OCI that works fine.
Try this option and pls let me know.
Regards,
Aslam A.S

FailUTF8Conv

Similar Messages

Maybe you are looking for