This content has been marked as final. Show 26 replies
Most probably, there is/are some characters in your remote database, which are of Char-set not supported by your local database.
So, when you are trying to pull those characters into your local database, Oracle is not allowing so because of conflicting Char-sets.
Please check the NLS settings of both databases.
These checks are becoming more and more strict as the Oracle versions are advancing. This is the reason previously (when it was 10G), this error was not raised.
check this -- http://vibhorkumar.wordpress.com/2011/02/27/fix-of-ora-29275-partial-multibyte-character/
Edited by: ranit B on Dec 22, 2012 2:18 PM
David Paul wrote:Don't confuse yourself... It's just saying to convert data into your local DB type...
Can you give me a full explaination about the DL http://vibhorkumar.wordpress.com/2011/02/27/fix-of-ora-29275-partial-multibyte-character/ you mentioned?
I don't understand the query in it well.
Check these queries -
Edited by: ranit B on Dec 22, 2012 5:46 PM
1] /* check this in both your LOCAL and REMOTE databases */ select dump('a',1010) from dual; I got -- Typ=96 Len=1 CharacterSet=AL32UTF8: 97 So, my charset encoding is AL32UTF8. Similarly, find yours for both Local & Remote DBs. 2] /* Then do */ CONVERT(transaction_reason,'<local_charset>','<remote_charset>')
could you please try the convert-command:
see [url http://docs.oracle.com/cd/E11882_01/server.112/e26088/functions034.htm#SQLRF00620]SQL-CONVERT
an example given there is
SELECT CONVERT('Ä Ê Í Õ Ø A B C D E ', 'US7ASCII', 'WE8ISO8859P1') FROM DUAL;
PS: This is already described above by ranit B above. Sorry for repeating. I overlooked it.
Edited by: stratmo on Dec 22, 2012 1:22 PM
Please check my last post... i've xplained.
And, could you please check and respond a little fast. We are stuck here since a long time. I don't like dragging issues. ;)
CREATE TABLE TEST_TMP AS SELECT CONVERT(TRANSACTION_REASON,'<REMOTE_CharacterSet>','<LOCAL_CharacterSet>') FROM APPS.MTL_TRANSACTION@OAPPS.COM --it is using db link. WHERE LAST_UPDATE_DATE>=TO_DATE('18-12-2012 22:01:58', 'dd-mm-yyyy hh24:mi:ss');
Please don't forget to mark post as 'Answered' when you get your desired result. Thanks.
David Paul wrote:This seems difficult coz this error is assoicated to a DDL like creating a table, which can only be realized in run-time.
It is helpful. But I have one doubt, is there a method to catch the issue before it raises?
Just try this once... Not tested
BEGIN execute immediate 'CREATE TABLE TEST_TMP AS SELECT CONVERT(TRANSACTION_REASON,''<REMOTE_CharacterSet>'',''<LOCAL_CharacterSet>'') FROM APPS.MTL_TRANSACTION@OAPPS.COM --it is using db link. WHERE LAST_UPDATE_DATE>=TO_DATE(''18-12-2012 22:01:58'', ''dd-mm-yyyy hh24:mi:ss'')'; EXCEPTION when others then DBMS_OUTPUT.PUT_LINE(SQLERRM); END;
Just now I tried the method by using 'CONVERT', but it still shows the error:
CREATE TABLE TEST_TMP
FROM APPS.MTL_TRANSACTION@OAPPS.COM --it is using db link.
WHERE LAST_UPDATE_DATE>=TO_DATE('18-12-2012 22:01:58', 'dd-mm-yyyy hh24:mi:ss');
Perhaps the unicode cannot be distinguished by the local database character set. so, it seems that I need to find other solutions to solve this issue.