Metadata character set translation

Hi does any one have an idea how to have your Aperture metadata info exported in the CP 1252 encoding? (Windows Western Europe). (Standard is MAC encoding.)
All my accents in French, German, Spanish and Dutch words come out garbled when I upload my photos to my photo agencies, or my web based Photoshelter archive.
I've tried a lot. So far my only solution is to export my files. Open them in FotoStation which has a conversion function. This is a lot of work though since adding and changing keywords in that program is extremely user unfriendly.
Any advice welcome!
Ronald

We bought SAP R3 system that uses base with WE8DEC set but saves character data in CL8ISO8859P5 for Russian languageI understand your configuration/requirement. The supported way for you to do this is to change your database character set to match the encoding of the data in the database. If you are sure they are all Russian data in CL8ISO8859P5 encoding formats (The Character set scanner utility shipped in 8.1.7 can assist you in verifying the data inside your db) .
Since your Oracle db supports SAP R3 , it is better if you contact SAP on whether they support the changing the db chacter set and the steps involved .

Similar Messages

Is there any character set translation facility between the database and th

We are upgrading a character based SQLforms version 3 application to forms6i running over the web against a 9.02 database.
Is there any character set translation facility between the database and the Forms server / web browser?
Our database character set is NEE..P4 (North European). However, the user needs to see the data in the BLT..P13 (Baltic) character set.
In the old application, users accessed these forms through a telnet client and this did the translation. For example :
The database character :
� (Unicode hex value = 00D0)
would be translated by and displayed on the telnet client as :
� (Unicode hex value = 0160)
A colleague of mine has done some experimenting. By changing the NLS_LANG registry setting to BLT..P13 in his oracle home and loading the Baltic character set for his Windows 2000 environment, he has been able to achieve the same translation in SQLPLUS.
However, we have been unable to do the same in a forms web runtime.

Oracle automatically translates characters between the display CharacterSet and the database characterset
The statement
In the old application, users accessed these forms through a telnet client and this did the translation
worries me a little because it implies that the data you have stored in the database might not actually encode the characters that you think you've put in.
This aside you need to set you NLS_LANG parameter on the application server for the client side character set - if you are using the forms listener servlet architecture then this would be set in the default.env file.

Big5 go ZH Character Set Translation

Dear all
Any build-in package inside Oracle can translate Big5 to ZH character encoding
Thank you
Kwan
17 Sept 2003

Certainly, a bit more information about what you're trying to accomplish would be helpful.
If you have a client whose NLS settings indicate it's using the Big5 character set and your database uses the ZH character set, Oracle's networking layer will automatically and transparently do the conversion.
Justin

Character set fundamentals

Can anyone give a definition of what a Character set is?(In laymen's terms, please.) . Wikipedia article was a bit scary. Then i found some other links which were easy to understand. This is what i found from an Oreilly book:
Each 7-bit ASCII character is represented as a sequence of seven bits within an eight-bit byte. The letter G, then, is represented as 0100 0111.Look at that same string of bits as a number, and you end up with 0x47 (hexadecimal) or 71(decimal)
ie the ASCII representation of G is 71 (try SELECT ASCII ('G') FROM DUAL; )
Forget the hexadecimal(because i always get intimidated when i hear the words hexa,oct,..ect); how did 0100 0111 become 71?

Can anyone give a definition of what a Character set
is?(In laymen's terms, please.) The best definition I can come up with is a character set translates the series of bits on disk into a character that a human can read. There are lots of different character sets because there are a lot of different languages in the world and lots of special characters. Different character sets allow you to use the same set of bits on disk to represent different characters in different regions (i.e. systems in Australia probably don't need to be able to represent Thai characters, systems in Thailand probably don't need to be able to represent Turkish characters, etc) There are also "universal" character sets called Unicode that encode just about every character known to man in a single character set, but that can increase storage requirements because there are so many characters that need to be represented.
Forget the hexadecimal(because i always get
intimidated when i hear the words hexa,oct,..ect);
how did 0100 0111 become 71?0100 0111 is a binary number. Just like in "normal" base 10 representation you can think of the number 123 as 100 + 2*100 + 3*1, in base 2 you can think for the number 0100 0111 as
0*2^7 + 1*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 1*2^2 + 1*2^1 + 1*2^0
=64 + 4 + 2 + 1
=71
Justin

Character set conversion on heterogeneous queries?

Hi,
We have an Oracle 11g (11.1.0.7.0) database running on a Windows 2003 SP1 server. Heterogeneous connectivity has been implemented to an MS SQL Server (2002) database. Whilst the link itself is working correctly, with queries returning expected results, we are however experiencing a problem with character set conversion. For example the French character é (e-acute) is not being translated correctly and results in an "ORA-29275: partial multibyte character", when queries are made against the table row containing this character.
The SQL Server database uses the ISO8859-1 character set and our database is using AL32UTF8.
In the initSID.ora configuration file for the heterogeneous link, we have defined the character set (used by SQL Server) as follows:
HS_LANGUAGE=american_america.we8iso8859p1
However this has not resulted in character set translation taking place.
We have also tried adjusting the "Perform translation for character data" option in the MS ODBC driver. This has not yielded the desired result either.
What I would like to know is:
(1) How to correctly configure a heterogeneous link to perform character set translation?
(2) If (1) above is not possible, then what alternative options are there, to achieve this?
Thanks,
William Walker

In general the conversation should work. You need to make sure no character conversation is enabled in the ODBC driver and for WE8 characters even no HS_LANGUAGE needs to be set in the gateway config file.
Most commonly the corrupted output is happening, because the application which is used to view the characters is not unicode compliant. So to dig into your issue I would suggest:
1. Use SQl Developer as client - SQL Developer is unicode compliant and available for free from: http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html
2. When you now select from your table, are the characters displayed now correctly?
If not, please continue:
3. Now create in your SQL Server a demo table (if possible:
create table french_char (col1 integer, col2 varchar(20));
and insert a demo record:
insert into french_char values (1,'éèç')
4. Use SQL Developer and the gateway to select from this demo table:
select "col1", "col2", dump("col2",16) from "french_char"@<your database link>;
and provide the output.
Also check out the ORACLE registry key belonging to the ORACLE_HOME containing DG4ODBC installation and provide me the NLS_LANG setting.

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

US7ASCII and WE8 character set compatibility

Hello,
I want to build two separates environments : one for development, one for production.
I have currently installed OWB 9.2.0.2.8 on a WE8 character set database version 9.2.0.5. This is the development database that contains the design repository, the runtime repository and the targets schemas.
The production database on which I'll run the packages is an US7ASCII database wersion 9.2.0.5. so, again, I will install on it the design repository, the runtime repository and the targets schemas.
My strategy is to export a MDL file for each project, from the development repository and then import it into the production repository. Then, I will change and register the locations and generate/deploy the project to the production target schema.
my questions are :
- Is is possible to import into a US7ASCII database (production) a MDL coming from a WE8 (development) database ?
- Can the generated packages process with some sources tables in an WE8 database even if the target is a US7ASCII table ? if yes, are the french accents still supported ?
Is my stategy correct or must I work with similar character set databases?
Thanks

Hello,
We finally created a new US7ASCII database. Then, we have installed OWB in this database.
OWB version must be greater than 9.2.0.4.
1) from the WE8 repository we export the metadata in US7ASCII characterset to a file
2) from the US7ASCII characterset repository we import the metadata file just created.
==> In the US7ASCII characterset repository , all the characters with accentuation are replaced with others characters. For example é become a "["
==> we created a mapping in the US7ASCII characterset repository. The source is a WE8 characterset table. At execution the accentuation characters are translated to a non accentuation character. For example, the "é" character become an "e"
In conclusion we will not use any accent characters in our repository.
regards

Problem with Character Set in Oracle database 10g

Hi,
I tried to import one tablespace into test server. Source server with Oracle 8i and Target server with Oracle database 10g. The error I get is
Import: Release 10.2.0.1.0 - Production on Thu Aug 3 00:20:49 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Username: sys as sysdba
Password:
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:V08.01.07 via conventional path
About to import transportable tablespace(s) metadata...
import done in WE8DEC character set and AL16UTF16 NCHAR character set
export server uses WE8DEC NCHAR character set (possible ncharset conversion)
. importing SYS's objects into SYS
. importing SYS's objects into SYS
IMP-00017: following statement failed with ORACLE error 19736:
"BEGIN sys.dbms_plugts.beginImport ('8.1.7.4.0',2,'2',NULL,'NULL',67051,25"
"51,2); END;"
IMP-00003: ORACLE error 19736 encountered
ORA-19736: can not plug a tablespace into a database using a different national character set
ORA-06512: at "SYS.DBMS_PLUGTS", line 2386
ORA-06512: at "SYS.DBMS_PLUGTS", line 1946
ORA-06512: at line 1
IMP-00000: Import terminated unsuccessfully
PLZ somebody help in geting resolve this. Has anybody seen this error before.

The solution to this problem is described in MetaLink note #211920.1. But this note is published with LIMITED access as it involves using a hidden parameter.
You can get access to the note through Oracle Support only.
The problem itself is solved generically, if the source database is at least 10.1.0.3 and the target database is 10.2
-- Sergiusz

Ora-12704: character set mismatch

I'm trying to insert string data into a nvarchar2 column using jdbc and I keep getting the error, ora-12704: character set mismatch. How do I avoid this without using the translate function? I believe my nls variables are all set correctly. Our software will eventually be in Korean.

Both my database and national character sets are UTF8.
We are trying to design a system
that supports internationalization. Majority
of our customers will be using English but we do have Korean customers. All their data will be in korean. It is my understanding (and I could be wrong) that the korean character set is varying multi-byte. This understanding has lead me to believe I need to define my "character" columns as nchar and nvarchar2. Is this assumption wrong?
Also, my nls_lang environment variable is AMERICAN_AMERICA.UTF8. I'm currently running Oracle 8.1.6. We have received 8.1.7 but I haven't upgraded yet.
Thanks in advance!

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;

Character sets in RTF messages not working with RTFEditorKit

I'm using RTFEditorKit.read() to get the text from an RTF document. The text is written in Russian and starts with the following
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\froman\fprq2\fcharset204{\*\fname
Times New Roman;}Times New Roman CYR;}{\f1\fswiss\fprq2\fcharset0 Arial;}}
{\colortbl ;\red0\green0\blue128;\red0\green0\blue0;}
\viewkind4\uc1\pard\tx360\cf1\f0\fs20\'c1\'ee\'eb\'fc\'f8\'e8\'ed\'f1\'f2\'e2\'eeThe reader sets the translation table based on the \ansi\ at the start of the document, which simply maps all bytes to themselves. The initial text, which should be 'Большинство', is then converted as latin-1. The 'fcharset204', which is CP1251, is completely ignored, and there's a lovely line in the RTFReader class
/* TODO: per-font font encodings ( \fcharset control word ) ? */Does anyone know how to extract non latin1 text from RTF or what other tools can be used to extract text from RTF.
Thanks
Antony

Hello,
Specifying the character set for a WebLogic webservice (see:
http://edocs.bea.com/wls/docs81/webserv/i18n.html#1069629) is one of the
many enhancements made since the 6.1 release. If possible, the best
solution for your webservice development would be to upgrade.
Bruce
"özkan Demir" wrote:
>
Hi all;
I am developing RPC style webservices on weblogic server 6.1 with service pack
2.
I have a problem about character sets. I have to turkish language so that the
character sets must be ISO-8859-9. But the soap messages are default UTF-8 so
that turkish characters becomes undetermined.
Is there a way that I can send soap messages in ISO-8859-9 character set or what
do I have to solve the problem of turkish characters between the client and the
server applications with webservices...Please Help!
Thanks

Inbound MQ with extended character sets

Hi
We are trying to send to PI data containing Swedish characters in both xml and non xml payloads.
The message is placed on an MQ queue (version 6.0.2.3) with a JMS header that has a ccsid of 1208 specified.
The PI adapter is specified as JMS | WebsphereMQ (non-JMS) | JMS Compliant and the payload module has
AF/Modules/MessageTransformerBean | Plain2XML | Transform.ContentType | text/xml;charset=utf-8
The received characters are not displaying correctly, which is a theme on several threads from the past but I've been unable to determine the solution.
I am more familiar of the MQ side so please excuse my bias. I already send extended character sets to other applications using jms over mq and we've tried using the same values on the MQ side to not avail.
In MQ we set the MQ header to the queue manager default but there is a jms specific additional header preceding the payload that specifies that the payload is utf-8.
From my perspecitve I can't see that PI is reading the JMS header at all (in fact if I remove it it has not effect) but we want it there in order to set some extended metadata properties.
When I look at the data on my queue as it leaves MQ it looks correct to view and in hex.
How do I get PI to recognise the JMS properties I've specified (its known as an mqrfh header in MQ).
Any advice, guidance, documentation to a PI novice would be most welcome.
Tim

Thankyou for the replies Sarvesh and Stefan.
I had read your previous replies on this subject, but was still stuck.
The delay in rep[lying is because we were wating for a reply from the Sap Support team.
They have now acknowledged that there may be a fault in the MessageTransformBean.
Its still only a may, but at the moment all your other suggestions have been used but not worked.
I'll update again when I get further information.
Tim

Approach to converting database character set from Western European to Unicode

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

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

Migration from 9i to 11g Transparent Gateway results in a) ORA-12704: character set mismatch b) ORA-02070: database ... does not support SYS_OP_C2C in this context

Migration from 9i to 11g Transparent Gateway results in a) ORA-12704: character set mismatch b) ORA-02070: database ... does not support SYS_OP_C2C in this context
What Transparent Gateway (TG) 11g configuration steps prevent the following errors?:
a) ORA-12704: character set mismatch
b) ORA-02070: database <DB_link_name> does not support SYS_OP_C2C in this context
Hints:
The current 9i TG works with the existing views and packages. These same db objects will not compile using the new 11g TG.
The db objects are on an Oracle 10g database linked to an SQL Server 2008 R2 database.
Since the 9i TG works I assume a configuration to the 11g TG will get it working same as before. But what...
Is is something controlled by these parameters? (Sorry, I don't know how this stuff works. I'm the application developer. My DBAs setup the Transparent Gateways.):
Parameters in the Gateway Startup Shell script:
    ORA_NLS33
    NLS_LANG
Parameters in the initsid.ora file:
    HS_LANGUAGE
    HS_NLS_DATE_FORMAT
    HS_NLS_DATE_LANGUAGE
I'm avoiding the known workaround to refactor the VIEWS and PACKAGES to contain CAST() statements to explicitly match the data types. A server side fix to the 11g TG is preferred.
Sample code:
a) ORA-12704: character set mismatch
   ... is caused by SQL that works with my 9i TG but not with my 11g TG. It's a snippit from my view that won't compile:
                  select status_code                  -- Oracle VARCHAR2(30)
                  from   ora_app_interfaces
                 UNION
                  select "StatusCode" as status_code -- SQL Server NVARCHAR(30)
                  from   SqlAppInterfaces
   Example workaround that I'm avoiding:
                  select status_code
                  from   ora_app_interfaces
                 UNION
                  select CAST("StatusCode" as VARCHAR(30)) as status_code
                  from   SqlAppInterfaces
b) ORA-02070: database <DB_link_name> does not support SYS_OP_C2C in this context
   A line of code in the procedure that compiles correctly but fails to execute:
           -- Insert into SQL Server from Oracle
           insert into PatientMedRecNum (
              "PatID",         -- SQL Server INT
              "MedRecNum",     -- SQL Server NVARCHAR(11)
              "Hospital")      -- SQL Server NVARCHAR(30)
           values (
              pi_pat_id,       -- Oracle NUMBER
              pi_med_rec_num, -- Oracle VARCHAR2
              pi_hospital);    -- Oracle VARCHAR2
I'd guess the errors are caused by the TG's implicit conversion between the Oracle VARCHAR2 and the SQL Server NVARCHAR... but this works fine on the 9i TG... how do I set it up to work on the 11g TG?
Thanks!

Trace of 11g TG... generating errors due to lack of automatic mapping from SQL NVARCHAR to Oracle NVARCHAR, where the previous 9g TG mapped from SQL NVARCHAR to Oracle VARCHAR2.
Oracle Corporation --- MONDAY    SEP 22 2014 13:35:08.186
Heterogeneous Agent Release
11.2.0.4.0
Oracle Corporation --- MONDAY    SEP 22 2014 13:35:08.186
Version 11.2.0.4.0
Entered hgogprd
HOSGIP for "HS_FDS_TRACE_LEVEL" returned "DEBUG"
Entered hgosdip
setting HS_OPEN_CURSORS to default of 50
setting HS_FDS_RECOVERY_ACCOUNT to default of "RECOVER"
setting HS_FDS_RECOVERY_PWD to default value
setting HS_FDS_TRANSACTION_LOG to default of HS_TRANSACTION_LOG
setting HS_IDLE_TIMEOUT to default of 0
setting HS_FDS_TRANSACTION_ISOLATION to default of "READ_COMMITTED"
setting HS_NLS_NCHAR to default of "UCS2"
setting HS_FDS_TIMESTAMP_MAPPING to default of "DATE"
setting HS_FDS_DATE_MAPPING to default of "DATE"
setting HS_RPC_FETCH_REBLOCKING to default of "ON"
setting HS_FDS_FETCH_ROWS to default of "100"
setting HS_FDS_RESULTSET_SUPPORT to default of "FALSE"
setting HS_FDS_RSET_RETURN_ROWCOUNT to default of "FALSE"
setting HS_FDS_PROC_IS_FUNC to default of "FALSE"
setting HS_FDS_MAP_NCHAR to default of "TRUE"
setting HS_NLS_DATE_FORMAT to default of "YYYY-MM-DD HH24:MI:SS"
setting HS_FDS_REPORT_REAL_AS_DOUBLE to default of "FALSE"
setting HS_LONG_PIECE_TRANSFER_SIZE to default of "65536"
setting HS_SQL_HANDLE_STMT_REUSE to default of "FALSE"
setting HS_FDS_QUERY_DRIVER to default of "FALSE"
setting HS_FDS_SUPPORT_STATISTICS to default of "TRUE"
setting HS_FDS_QUOTE_IDENTIFIER to default of "TRUE"
setting HS_KEEP_REMOTE_COLUMN_SIZE to default of "OFF"
setting HS_FDS_GRAPHIC_TO_MBCS to default of "FALSE"
setting HS_FDS_MBCS_TO_GRAPHIC to default of "FALSE"
setting HS_CALL_NAME_ISP to "gtw$:SQLTables;gtw$:SQLColumns;gtw$:SQLPrimaryKeys;gtw$:SQLForeignKeys;gtw$:SQLProcedures;gtw$:SQLStatistics;gtw$:SQLGetInfo"
setting HS_FDS_DELAYED_OPEN to default of "TRUE"
setting HS_FDS_WORKAROUNDS to default of "0"
setting HS_FDS_ARRAY_EXEC to default of "TRUE"
Exiting hgosdip, rc=0
ORACLE_SID is "xxxDEV"
Product-Info:
Port Rls/Upd:4/0 PrdStat:0
Agent:Oracle Database Gateway for MSSQL
Facility:hsa
Class:MSSQL, ClassVsn:11.2.0.4.0_0019, Instance:xxxDEV
Exiting hgogprd, rc=0
Entered hgoinit
HOCXU_COMP_CSET=1
HOCXU_DRV_CSET=178
HOCXU_DRV_NCHAR=1000
HOCXU_DB_CSET=178
HS_LANGUAGE not specified
rc=1239980 attempting to get LANG environment variable.
HOCXU_SEM_VER=102000
Entered hgolofn at 2014/09/22-13:35:08
RC=-1 from HOSGIP for "PATH"
Setting PATH to "C:\oracle\product\11.2.0\tg_2\dg4msql\driver\lib"
Exiting hgolofn, rc=0 at 2014/09/22-13:35:08
HOSGIP for "HS_OPEN_CURSORS" returned "50"
HOSGIP for "HS_FDS_FETCH_ROWS" returned "100"
HOSGIP for "HS_LONG_PIECE_TRANSFER_SIZE" returned "65536"
HOSGIP for "HS_NLS_NUMERIC_CHARACTER" returned ".,"
HOSGIP for "HS_KEEP_REMOTE_COLUMN_SIZE" returned "OFF"
HOSGIP for "HS_FDS_DELAYED_OPEN" returned "TRUE"
HOSGIP for "HS_FDS_WORKAROUNDS" returned "0"
HOSGIP for "HS_FDS_MBCS_TO_GRAPHIC" returned "FALSE"
HOSGIP for "HS_FDS_GRAPHIC_TO_MBCS" returned "FALSE"
treat_SQLLEN_as_compiled = 1
Exiting hgoinit, rc=0 at 2014/09/22-13:35:08
Entered hgolgon at 2014/09/22-13:35:08
reco:0, name:abaccess, tflag:0
Entered hgosuec at 2014/09/22-13:35:08
uencoding=UTF16
Entered shgosuec at 2014/09/22-13:35:08
Exiting shgosuec, rc=0 at 2014/09/22-13:35:08
shgosuec() returned rc=0
Exiting hgosuec, rc=0 at 2014/09/22-13:35:08
HOSGIP for "HS_FDS_RECOVERY_ACCOUNT" returned "RECOVER"
HOSGIP for "HS_FDS_TRANSACTION_LOG" returned "HS_TRANSACTION_LOG"
HOSGIP for "HS_FDS_TIMESTAMP_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_DATE_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_MAP_NCHAR" returned "TRUE"
HOSGIP for "HS_FDS_RESULTSET_SUPPORT" returned "FALSE"
HOSGIP for "HS_FDS_RSET_RETURN_ROWCOUNT" returned "FALSE"
HOSGIP for "HS_FDS_PROC_IS_FUNC" returned "FALSE"
HOSGIP for "HS_FDS_REPORT_REAL_AS_DOUBLE" returned "FALSE"
HOSGIP for "HS_FDS_DEFAULT_OWNER" returned "dbo"
HOSGIP for "HS_SQL_HANDLE_STMT_REUSE" returned "FALSE"
Entered hgocont at 2014/09/22-13:35:08
HS_FDS_CONNECT_INFO = "sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV"
RC=-1 from HOSGIP for "HS_FDS_CONNECT_STRING"
Entered hgogenconstr at 2014/09/22-13:35:08
dsn: sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV, name:xxx_admin
optn:
Entered hgocip at 2014/09/22-13:35:08
dsn:sqlserverxxx/sqlinstancexxx/SQL_Server_2008_xxx_DEV
Exiting hgocip, rc=0 at 2014/09/22-13:35:08
Entered shgogohn at 2014/09/22-13:35:08
ohn is 'OraGtw11g_home2'
Exiting shgogohn, rc=0 at 2014/09/22-13:35:08
RC=-1 from HOSGIP for "HS_FDS_ENCRYPT_SESSION"
using 0 as default value for "HS_FDS_ENCRYPT_SESSION"
RC=-1 from HOSGIP for "HS_FDS_VALIDATE_SERVER_CERT"
using 1 as default value for "HS_FDS_VALIDATE_SERVER_CERT"
Entered hgocont_OracleCsidToIANA at 2014/09/22-13:35:08
Returning 2252
Exiting hgocont_OracleCsidToIANA at 2014/09/22-13:35:08
Exiting hgogenconstr, rc=0 at 2014/09/22-13:35:08
Entered hgopoer at 2014/09/22-13:35:08
hgopoer, line 231: got native error 5701 and sqlstate 01000; message follows...
[Oracle][ODBC SQL Server Wire Protocol driver][Microsoft SQL Server]Changed database context to 'Xxx_XXX_DEV'. {01000,NativeErr = 5701}[Oracle][ODBC SQL Server Wire Protocol driver][Microsoft SQL Server]Changed language setting to us_english. {01000,NativeErr = 5703}
Exiting hgopoer, rc=0 at 2014/09/22-13:35:08
hgocont, line 2764: calling SqlDriverConnect got sqlstate 01000
Entered hgolosf at 2014/09/22-13:35:08
Exiting hgolosf, rc=0 at 2014/09/22-13:35:08
DriverName:HGmsss23.dll, DriverVer:07.01.0093 (B0098, U0065)
DBMS Name:Microsoft SQL Server, DBMS Version:10.00.2531
Exiting hgocont, rc=0 at 2014/09/22-13:35:08 with error ptr FILE:hgocont.c LINE:2764 ID:SQLDriverConnect
SQLGetInfo returns Y for SQL_CATALOG_NAME
SQLGetInfo returns 128 for SQL_MAX_CATALOG_NAME_LEN
Exiting hgolgon, rc=0 at 2014/09/22-13:35:08
Entered hgoulcp at 2014/09/22-13:35:08
Entered hgowlst at 2014/09/22-13:35:08
Exiting hgowlst, rc=1 at 2014/09/22-13:35:08
SQLGetInfo returns Y for SQL_PROCEDURES
SQLGetInfo returns 0x1f for SQL_OWNER_USAGE
TXN Capable:2, Isolation Option:0xf
SQLGetInfo returns 128 for SQL_MAX_SCHEMA_NAME_LEN
SQLGetInfo returns 128 for SQL_MAX_TABLE_NAME_LEN
SQLGetInfo returns 134 for SQL_MAX_PROCEDURE_NAME_LEN
HOSGIP returned value of "TRUE" for HS_FDS_QUOTE_IDENTIFIER
SQLGetInfo returns " (0x22) for SQL_IDENTIFIER_QUOTE_CHAR
13 instance capabilities will be uploaded
capno:1992, context:0x0001ffff, add-info:        0
capno:3042, context:0x00000000, add-info:        0, translation:"42"
capno:3047, context:0x00000000, add-info:        0, translation:"57"
capno:3049, context:0x00000000, add-info:        0, translation:"59"
capno:3050, context:0x00000000, add-info:        0, translation:"60"
capno:3066, context:0x00000000, add-info:        0
capno:3067, context:0x00000000, add-info:        0
capno:3068, context:0x00000000, add-info:        0
capno:3069, context:0x00000000, add-info:        0
capno:3500, context:0x00000001, add-info:       91, translation:"42"
capno:3501, context:0x00000001, add-info:       93, translation:"57"
capno:3502, context:0x00000001, add-info:      107, translation:"59"
capno:3503, context:0x00000001, add-info:      110, translation:"60"
Exiting hgoulcp, rc=0 at 2014/09/22-13:35:08
Entered hgouldt at 2014/09/22-13:35:08
NO instance DD translations were uploaded
Exiting hgouldt, rc=0 at 2014/09/22-13:35:08
Entered hgobegn at 2014/09/22-13:35:08
tflag:0 , initial:1
hoi:0x12ee18, ttid (len 32) is ...
xxx
xxx
tbid (len 10) is ...
0: 09000F00 0FAC1E00 010A [..........]
Exiting hgobegn, rc=0 at 2014/09/22-13:35:08
Entered hgodtab at 2014/09/22-13:35:08
count:1
table: XXX_INTERFACE
Allocate hoada[0] @ 0000000005F58270
Entered hgopcda at 2014/09/22-13:35:08
Column:1(InterfaceID): dtype:2 (NUMERIC), prc/scl:20/0, nullbl:0, octet:0, sign:1, radix:10
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:2(TableName): dtype:-9 (WVARCHAR), prc/scl:30/0, nullbl:0, octet:60, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:3(TableID): dtype:4 (INTEGER), prc/scl:10/0, nullbl:0, octet:0, sign:1, radix:10
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:4(StatusCode): dtype:-9 (WVARCHAR), prc/scl:30/0, nullbl:0, octet:60, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:5(StatusTimestamp): dtype:93 (TIMESTAMP), prc/scl:23/3, nullbl:0, octet:0, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
Entered hgopcda at 2014/09/22-13:35:08
Column:6(InterfaceLog): dtype:-9 (WVARCHAR), prc/scl:400/0, nullbl:1, octet:800, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/09/22-13:35:08
The hoada for table XXX_INTERFACE follows...
hgodtab, line 1073: Printing hoada @ 0000000005F58270
MAX:6, ACTUAL:6, BRC:1, WHT=6 (TABLE_DESCRIBE)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR,0x400:UNICODE_COLUMN)
DTY NULL-OK LEN MAXBUFLEN   PR/SC CST IND MOD NAME
3 DECIMAL N         22         22 20/ 0    0   0   0 InterfaceID
12 VARCHAR N         60         60 128/ 30 1000   0 440 TableName
4 INTEGER N          4 4   0/ 0    0   0   0 TableID
12 VARCHAR N         60         60 128/ 30 1000   0 440 StatusCode
91 DATE N         16         16 0/ 0    0   0   0 StatusTimestamp
12 VARCHAR Y        800        800 129/144 1000   0 440 InterfaceLog
Exiting hgodtab, rc=0 at 2014/09/22-13:35:08
Entered hgodafr, cursor id 0 at 2014/09/22-13:35:08
Free hoada @ 0000000005F58270
Exiting hgodafr, rc=0 at 2014/09/22-13:35:08
Entered hgotcis at 2014/09/22-13:35:08
Calling SQLStatistics for XXX_INTERFACE
IndexType=SQL_TABLE_STAT: cardinality=0
IndexType=1: PK_XXX_Interface
IndexType=3: IX_TableID
IndexType=3: IX_TableName
Calling SQLColumns for dbo.SQL_app_INTERFACE
#1 Column "InterfaceID": dtype=2, colsize=20, decdig=0, char_octet_length=0, cumulative avg row len=15
#2 Column "TableName": dtype=-9, colsize=30, decdig=0, char_octet_length=60, cumulative avg row len=60
#3 Column "TableID": dtype=4, colsize=10, decdig=0, char_octet_length=0, cumulative avg row len=64
#4 Column "StatusCode": dtype=-9, colsize=30, decdig=0, char_octet_length=60, cumulative avg row len=109
#5 Column "StatusTimestamp": dtype=93, colsize=23, decdig=3, char_octet_length=0, cumulative avg row len=125
#6 Column "InterfaceLog": dtype=-9, colsize=400, decdig=0, char_octet_length=800, cumulative avg row len=725
3 Index(es) found:
Index: PK_XXX_Interface, type=1, ASCENDING, UNIQUE, cardinality=0
#1 Column 1: InterfaceID
Index: IX_TableID, type=3, ASCENDING, NON-UNIQUE, cardinality=0
#1 Column 3: TableID
Index: IX_TableName, type=3, ASCENDING, NON-UNIQUE, cardinality=0
#1 Column 2: TableName
Exiting hgotcis, rc=0 at 2014/09/22-13:35:08

Conversion error, from character set 4102 to character set 4103

Hi,
We've developed a JCO server(in Java) with an ABAP report the function provided by the JCO server.
MetaData:
     static {
          repository = new Repository("SMSRepository");
          fmeta = new JCO.MetaData("ZSMSSEND");
          fmeta.addInfo("TO", JCO.TYPE_CHAR, 255,   0, 0, JCO.IMPORT_PARAMETER, null);
          fmeta.addInfo("CONTENT", JCO.TYPE_CHAR, 255,   0, 0, JCO.IMPORT_PARAMETER, null);
          fmeta.addInfo("RETN", JCO.TYPE_CHAR, 255,   0, 0, JCO.EXPORT_PARAMETER, null);
          repository.addFunctionInterfaceToCache(fmeta);
Server parameters:
       Properties prop = new Properties();
       prop.put("jco.server.gwhost","shaw2k07");
       prop.put("jco.server.gwserv","sapgw01");
       prop.put("jco.server.progid","JCOSERVER01");
       prop.put("jco.server.unicode","1");
       srv = new SMSServer(prop,repository);
If we run JCO server in both my client machine(from developer studio) and in the WAS machine(stand alone Java program), everything is ok. In the Abap side, the SM59 unicode test return the destination is an unicode system, and the ABAP report call the function can run smoothly.
But we package this JCO server to a web application and deploy to WAS, problem occured. The SM59 unicode test still say the destination is an unicode system. But the ABAP report runs with an ABAP DUMP:
Conversion error between two character set
RFC_CONVERSION_FIELD
Conversion error "RETN" from character set 4102 to character set 4103
A conversion error occurred during the execution of a Remote Function
Call. This happened either when the data was received or when it was
sent. The latter case can only occur if the data is sent from a Unicode
system to a non-Unicode system.
I read the jrfc.trc log, it shows it receives data in unicode 4103(that's ok), but send data in unicode 4102(that's the problem).4102 is UTF-16 Big Endian and 4103 UTF-16 Little Endian. Our system is windows on intel 32 aritechture, so based on Note 552464, it should be 4103.
Why it sends data (Java JCO server send output parameter to ABAP) in 4102?????
What's the problem??? Thank you very much!!
Best Regards,
Xiaoming Yang
Message was edited by:
        Xiaoming Yang

Hello Experts,
Any replies on this?
I am also getting a similar kind of error.
Do you have any idea on this?
Thanks and Best Regards,
Suresh

Metadata character set translation

Similar Messages

Maybe you are looking for