Upgrade to 5.0.2 - Character Sets?

We just upgraded to 5.0.2. We had experienced in 4.5 WS Some problems with characters not displaying in the portal (specifically, the Euro Symbol) In 4.5 WS we were able to change a user's account Regional Settings, the charater set used (for instance, using Western European (ISO - 8859-1)). However, I can't see anywhere to change that with 5.0.2.
Our Eurpean users want their currency symbol! Where can I change this?
Wendy Ramsaur
KSA

If the mapping has been removed you can add it by doing the following, although, if you install went haywire this won't help you much at all.
to create an application extension mapping with the following:
executable: C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
extension: .pt
limit verbs to GET, HEAD, POST
"check that files exist" should be unchecked
"Script engine" should be checked.

Similar Messages

ORA-12709: error while loading create database character set after upgrade

Dear All
i m getting ORA-12709: error while loading create database character set, After upgraded the database from 10.2.0.3 to 11.2.0.3 in ebusiness suit env.
current application version 12.0.6
please help me to resolve it.
SQL> startup;
ORACLE instance started.
Total System Global Area 1.2831E+10 bytes
Fixed Size 2171296 bytes
Variable Size 2650807904 bytes
Database Buffers 1.0133E+10 bytes
Redo Buffers 44785664 bytes
ORA-12709: error while loading create database character set
-bash-3.00$ echo $ORA_NLS10
/u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
export ORACLE_BASE=/u01/oracle
export ORACLE_HOME=/u01/oracle/PROD/db/tech_st/11.2.0
export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
export PERL5LIB=$ORACLE_HOME/perl/lib/5.10.0:$ORACLE_HOME/perl/site_perl/5.10.0
export ORA_NLS10=/u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
export ORACLE_SID=PROD
-bash-3.00$ pwd
/u01/oracle/PROD/db/tech_st/11.2.0/nls/data/9idata
-bash-3.00$ ls -lh |more
total 56912
-rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx00001.nlb
-rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00002.nlb
-rw-r--r-- 1 oracle oinstall 959 Jan 15 16:05 lx00003.nlb
-rw-r--r-- 1 oracle oinstall 984 Jan 15 16:05 lx00004.nlb
-rw-r--r-- 1 oracle oinstall 968 Jan 15 16:05 lx00005.nlb
-rw-r--r-- 1 oracle oinstall 962 Jan 15 16:05 lx00006.nlb
-rw-r--r-- 1 oracle oinstall 960 Jan 15 16:05 lx00007.nlb
-rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00008.nlb
-rw-r--r-- 1 oracle oinstall 940 Jan 15 16:05 lx00009.nlb
-rw-r--r-- 1 oracle oinstall 939 Jan 15 16:05 lx0000a.nlb
-rw-r--r-- 1 oracle oinstall 1006 Jan 15 16:05 lx0000b.nlb
-rw-r--r-- 1 oracle oinstall 1008 Jan 15 16:05 lx0000c.nlb
-rw-r--r-- 1 oracle oinstall 998 Jan 15 16:05 lx0000d.nlb
-rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx0000e.nlb
-rw-r--r-- 1 oracle oinstall 926 Jan 15 16:05 lx0000f.nlb
-rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00010.nlb
-rw-r--r-- 1 oracle oinstall 958 Jan 15 16:05 lx00011.nlb
-rw-r--r-- 1 oracle oinstall 956 Jan 15 16:05 lx00012.nlb
-rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx00013.nlb
-rw-r--r-- 1 oracle oinstall 970 Jan 15 16:05 lx00014.nlb
-rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00015.nlb
-rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00016.nlb
-rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00017.nlb
-rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00018.nlb
-rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00019.nlb
-rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx0001a.nlb
-rw-r--r-- 1 oracle oinstall 944 Jan 15 16:05 lx0001b.nlb
-rw-r--r-- 1 oracle oinstall 953 Jan 15 16:05 lx0001c.nlb
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /u01/oracle/PROD/db/tech_st/11.2.0
System name: SunOS
Node name: proddb3.zakathouse.org
Release: 5.10
Version: Generic_147440-19
Machine: sun4u
Using parameter settings in server-side spfile /u01/oracle/PROD/db/tech_st/11.2.0/dbs/spfilePROD.ora
System parameters with non-default values:
processes = 200
sessions = 400
timed_statistics = TRUE
event = ""
shared_pool_size = 416M
shared_pool_reserved_size= 40M
nls_language = "american"
nls_territory = "america"
nls_sort = "binary"
nls_date_format = "DD-MON-RR"
nls_numeric_characters = ".,"
nls_comp = "binary"
nls_length_semantics = "BYTE"
memory_target = 11G
memory_max_target = 12G
control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl01.dbf"
control_files = "/u01/oracle/PROD/db/tech_st/10.2.0/dbs/cntrl02.dbf"
control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl03.dbf"
db_block_checksum = "TRUE"
db_block_size = 8192
compatible = "11.2.0.0.0"
log_archive_dest_1 = "LOCATION=/u01/oracle/PROD/db/apps_st/data/archive"
log_archive_format = "%t_%s_%r.dbf"
log_buffer = 14278656
log_checkpoint_interval = 100000
log_checkpoint_timeout = 1200
db_files = 512
db_file_multiblock_read_count= 8
db_recovery_file_dest = "/u01/oracle/fast_recovery_area"
db_recovery_file_dest_size= 14726M
log_checkpoints_to_alert = TRUE
dml_locks = 10000
undo_management = "AUTO"
undo_tablespace = "APPS_UNDOTS1"
db_block_checking = "FALSE"
session_cached_cursors = 500
utl_file_dir = "/usr/tmp"
utl_file_dir = "/usr/tmp"
utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound"
utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound/PROD_proddb3"
utl_file_dir = "/usr/tmp"
plsql_code_type = "INTERPRETED"
plsql_optimize_level = 2
job_queue_processes = 2
cursor_sharing = "EXACT"
parallel_min_servers = 0
parallel_max_servers = 8
core_dump_dest = "/u01/oracle/PROD/db/tech_st/10.2.0/admin/PROD_proddb3/cdump"
audit_file_dest = "/u01/oracle/admin/PROD/adump"
db_name = "PROD"
open_cursors = 600
pga_aggregate_target = 1G
workarea_size_policy = "AUTO"
optimizer_secure_view_merging= FALSE
aq_tm_processes = 1
olap_page_pool_size = 4M
diagnostic_dest = "/u01/oracle"
max_dump_file_size = "20480"
Tue Jan 15 16:16:02 2013
PMON started with pid=2, OS id=18608
Tue Jan 15 16:16:02 2013
PSP0 started with pid=3, OS id=18610
Tue Jan 15 16:16:03 2013
VKTM started with pid=4, OS id=18612 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Tue Jan 15 16:16:03 2013
GEN0 started with pid=5, OS id=18616
Tue Jan 15 16:16:03 2013
DIAG started with pid=6, OS id=18618
Tue Jan 15 16:16:03 2013
DBRM started with pid=7, OS id=18620
Tue Jan 15 16:16:03 2013
DIA0 started with pid=8, OS id=18622
Tue Jan 15 16:16:03 2013
MMAN started with pid=9, OS id=18624
Tue Jan 15 16:16:03 2013
DBW0 started with pid=10, OS id=18626
Tue Jan 15 16:16:03 2013
LGWR started with pid=11, OS id=18628
Tue Jan 15 16:16:03 2013
CKPT started with pid=12, OS id=18630
Tue Jan 15 16:16:03 2013
SMON started with pid=13, OS id=18632
Tue Jan 15 16:16:04 2013
RECO started with pid=14, OS id=18634
Tue Jan 15 16:16:04 2013
MMON started with pid=15, OS id=18636
Tue Jan 15 16:16:04 2013
MMNL started with pid=16, OS id=18638
DISM started, OS id=18640
ORACLE_BASE from environment = /u01/oracle
Tue Jan 15 16:16:08 2013
ALTER DATABASE MOUNT
ORA-12709 signalled during: ALTER DATABASE MOUNT...

ORA-12709 signalled during: ALTER DATABASE MOUNT...Do you have any trace files generated at the time you get this error?
Please see these docs.
ORA-12709: WHILE STARTING THE DATABASE [ID 1076156.6]
Upgrading from 9i to 10gR2 Fails With ORA-12709 : Error While Loading Create Database Character Set [ID 732861.1]
Ora-12709 While Trying To Start The Database [ID 311035.1]
ORA-12709 when Mounting the Database [ID 160478.1]
How to Move From One Database Character Set to Another at the Database Level [ID 1059300.6]
Thanks,
Hussein

Problem with Character Set after upgrade

Hello,
I have a probelm and was wondering if anyone has seen this before.
I have been running Java 1.4.2_13 for a while now on some Windows servers. About a month ago we upgraded to Java 1.6.0_12.
We are reading input files that are in the character set Big5 HKSCS. After the upgrade our application started to report certain characters as invalid. Some of the characters are 0xD843, 0xD844.
These should be valid characters and were in the previous version of Java (1.4.2_13).
Has anyone seen this?
Thanks in advance,
Jerry

The [Supported Encodings|http://java.sun.com/javase/6/docs/technotes/guides/intl/encoding.doc.html] page for the Java 6 release describes that charset as
Big5 with Hong Kong extensions, Traditional Chinese (incorporating 2001 revision)You would know more than I do about that 2001 revision (or at least, not less than I do, since I know nothing about it). Perhaps that's the source of your problem?
Edit: especially since the [Supported Encodings|http://www.j2ee.me/j2se/1.4.2/docs/guide/intl/encoding.doc.html] page for Java 1.4 doesn't mention the 2001 revision.

Message uses a character set that is not supported by the internet service

Does any one have any advice on how to fix this problem?
E-mails sent from my iphone 3G periodically arrive in an unreadable form at the recipient. The body of the e-mail has been replaced with the message "This message uses a character set that is not supported by the internet service...." The problem e-mails also include an attachment that contains an unformatted text file containing the original message surrounded by what appears to be lots of formatting data that is displayed as gibberish.
This occurs sometimes, but not always, even with the same recipients. I am sending e-mail through a G-mail account that is configured on the iphone using IMAP. I have tried the gmail account to use the two available formatting options for mail, but neither fixes the problem.
I have also upgraded to 2.01 and restored a few times without impact.

Hi,
I got somewhat similar problem with special charecters(German umlaud �,�,�..).
I create a file with java having special charecters in it. Now if I open this file I am able to view the special charecters in it.But If I attach this file send it using following code then receiver can not see the umlaud charecters in it.They get replaced by _ or ?
MimeBodyPart mbp2 = new MimeBodyPart();
FileDataSource fds = new FileDataSource(fileName);
mbp2.setDataHandler(new DataHandler(fds));
mbp2.setFileName(output.getName());
Multipart mp = new MimeMultipart();
mp.addBodyPart(mbp2);
msg.setContent(mp);
Transport.send(msg);
From you message it looks like you are able to send the mail attachment correctly(by preserving special charecters).
Can you tell me what might be wrong in my code.
I appriciate your efforts in advance.
Prasad

Arabic Character set conversion-help needed

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

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

Character set marker unknown error while importing data in 10g from 8i

Hi All,
I am trying to import the whole database schema wise (one by one) through oracle 10g database control page (which is browser based)
But when i try to import the objects of a schema i get the error that
"IMP-00037 : Character set marker unknown "
Import terminated unsuccessfully
Would anybody please tell me about the mentioned error ???
Kindly provide the solution.
Mentioned below are the character sets available in both the version.
Character sets in oracle 8.1.7 :-
Database Character Set :: WE8ISO8859P1
National Character Set :: WE8ISO8859P1
Character sets in oracle 10.2.0.1.0 :-
Database Character Set :: WE8ISO8859P1
National Character Set :: AL16UTF16
Regards
Milin...
Message was edited by:
user640001

Hi,
As you have asked, i have mentioned the export command below to get the full database export file.
And I have copied this export file (dump) to another machine(Server) where i have to import that file to upgrade the database to 10g Rel 2.
SET CC=%DATE:~4,2%-%DATE:~7,2%-%DATE:~10,4%
exp username/password@db_name
file=D:\PAY_BKP\EXP_FULL_PAY_%CC%.DMP log=D:\PAY_BKP\EXP_FULL_PAY.log
indexes=yes
full=yes
Kindly provide guidance.
Regards
Milin

Character set mismatch in copying from oracle to oracle

I have a set of ODI scripts that are copying from a source JD Edwards ERP database (Oracle 10g) to a BI datamart (Oracle 10g) and all the original scripts work OK.
However I have mapped on to some additional tables in the ERP source database and some new BI tables in the target datamart database (oracle - to - oracle) but get an error when I try ro execute these.
The operator log shows that the error is in the 'INSERT FLOW INTO I$ TABLE' and the error is ORA-12704 character set mismatch.
The character set for both Oracle databases are the same (and have not changed) the main NLS_CHARACTERSET is AL332UTF8 and the national NLS_NCHAR_CHARACTERSET is AL16UTF16.
But this works for tables containing NCHAR and NUMBER in previous scripts but not for anything I write now.
The only other difference is that there was a recent upgrade of ODI to 10.1.3.5 - the repositories are also upgraded.
Any ideas ?

Hi Ravi,
yes, a gateway would help. In 11.2 Oracle offers 2 kind of gateways to a SQL Server - a gateway for free which is based on 3rd party ODBC drivers (you need to get them from a 3rd party vendor, they are not included in the package) and called Database Gateway for ODBC (=DG4ODBC) and a very powerful Database Gateway for MS SQL Server (=DG4MSQL) which allows you also to execute distributed transactions and call remote SQL Server stored procdures. Please keep in mind that DG4MSQL requires a separate license.
As you didn't post which platform you're going to use, please check out On "My Oracle Support" (=MOS) where you'll find notes how to configure each gateway for all supported platforms - just look for DG4MSQL or DG4ODBC
On OTN you'll find the also the manuals.
DG4ODBC: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12070.pdf
DG4MSQL: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12069.pdf
The generic gateway installation for Unix: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12013.pdf
and for Windows: http://download.oracle.com/docs/cd/E11882_01/gateways.112/e12061.pdf

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!

Fixing a US7ASCII - WE8ISO8859P1 Character Set Conversion Disaster

In hopes that it might be helpful in the future, here's the procedure I followed to fix a disastrous unintentional US7ASCII on 9i to WE8ISO8859P1 on 10g migration.
BACKGROUND
Oracle has multiple character sets, ranging from US7ASCII to AL32UTF16.
US7ASCII, of course, is a cheerful 7 bit character set, holding the basic ASCII characters sufficient for the English language.
However, it also has a handy feature: character fields under US7ASCII will accept characters with values > 128. If you have a web application, users can type (or paste) Us with umlauts, As with macrons, and quite a few other funny-looking characters.
These will be inserted into the database, and then -- if appropriately supported -- can be selected and displayed by your app.
The problem is that while these characters can be present in a VARCHAR2 or CLOB column, they are not actually legal. If you try within Oracle to convert from US7ASCII to WE8ISO8859P1 or any other character set, Oracle recognizes that these characters with values greater than 127 are not valid, and will replace them with a default "unknown" character. In the case of a change from US7ASCII to WE8ISO8859P1, it will change them to 191, the upside down question mark.
Oracle has a native utility, introduced in 8i, called csscan, which assists in migrating to different character sets. This has been replaced in newer versions with the Database MIgration Assistant for Unicode (DMU), which is the new recommended tool for 11.2.0.3+.
These tools, however, do no good unless they are run. For my particular client, the operations team took a database running 9i and upgraded it to 10g, and as part of that process the character set was changed from US7ASCII to WE8ISO8859P1. The database had a large number of special characters inserted into it, and all of these abruptly turned into upside-down question marks. The users of the application didn't realize there was a problem until several weeks later, by which time they had put a lot of new data into the system. Rollback was not possible.
FIXING THE PROBLEM
How fixable this problem is and the acceptable methods which can be used depend on the application running on top of the database. Fortunately, the client app was amenable.
(As an aside note: this approach does not use csscan -- I had done something similar previously on a very old system and decided it would take less time in this situation to revamp my old procedures and not bring a new utility into the mix.)
We will need to separate approaches -- one to fix the VARCHAR2 & CHAR fields, and a second for CLOBs.
In order to set things up, we created two environments. The first was a clone of production as it is now, and the second a clone from before the upgrade & character set change. We will call these environments PRODCLONE and RESTORECLONE.
Next, we created a database link, OLD6. This allows PRODCLONE to directly access RESTORECLONE. Since they were cloned with the same SID, establishing the link needed the global_names parameter set to false.
alter system set global_names=false scope=memory;
CREATE PUBLIC DATABASE LINK OLD6
CONNECT TO DBUSERNAME
IDENTIFIED BY dbuserpass
USING 'restoreclone:1521/MYSID';
Testing the link...
SQL> select count(1) from users@old6;
COUNT(1)
       454
Here is a row in a table which contains illegal characters. We are accessing RESTORECLONE from PRODCLONE via our link.
PRODCLONE> select dump(title) from my_contents@old6 where pk1=117286;
DUMP(TITLE)
Typ=1 Len=49: 78,67,76,69,88,45,80,78,174,32,69,120,97,109,32,83,116,121,108,101
,32,73,110,116,101,114,97,99,116,105,118,101,32,82,101,118,105,101,119,32,81,117
,101,115,116,105,111,110,115
By comparison, a dump of that row on PRODCLONE's my_contents gives:
PRODCLONE> select dump(title) from my_contents where pk1=117286;
DUMP(TITLE)
Typ=1 Len=49: 78,67,76,69,88,45,80,78,191,32,69,120,97,109,32,83,116,121,108,101
,32,73,110,116,101,114,97,99,116,105,118,101,32,82,101,118,105,101,119,32,81,117
,101,115,116,105,111,110,115
Note that the "174" on RESTORECLONE was changed to "191" on PRODCLONE.
We can manually insert CHR(174) into our PRODCLONE and have it display successfully in the application.
However, I tried a number of methods to copy the data from RESTORECLONE to PRODCLONE through the link, but entirely without success. Oracle would recognize the character as invalid and silently transform it.
Eventually, I located a clever workaround at this link:
https://kr.forums.oracle.com/forums/thread.jspa?threadID=231927
It works like this:
On RESTORECLONE you create a view, vv, with UTL_RAW:
RESTORECLONE> create or replace view vv as select pk1,utl_raw.cast_to_raw(title) as title from my_contents;
View created.
This turns the title to raw on the RESTORECLONE.
You can now convert from RAW to VARCHAR2 on the PRODCLONE database:
PRODCLONE> select dump(utl_raw.cast_to_varchar2 (title)) from vv@old6 where pk1=117286;
DUMP(UTL_RAW.CAST_TO_VARCHAR2(TITLE))
Typ=1 Len=49: 78,67,76,69,88,45,80,78,174,32,69,120,97,109,32,83,116,121,108,101
,32,73,110,116,101,114,97,99,116,105,118,101,32,82,101,118,105,101,119,32,81,117
,101,115,116,105,111,110,115
The above works because oracle on PRODCLONE never knew that our TITLE string on RESTORE was originally in US7ASCII, so it was unable to do its transparent character set conversion.
PRODCLONE> update my_contents set title=( select utl_raw.cast_to_varchar2 (title) from vv@old6 where pk1=117286) where pk1=117286;
PRODCLONE> select dump(title) from my_contents where pk1=117286;
DUMP(UTL_RAW.CAST_TO_VARCHAR2(TITLE))
Typ=1 Len=49: 78,67,76,69,88,45,80,78,174,32,69,120,97,109,32,83,116,121,108,101
,32,73,110,116,101,114,97,99,116,105,118,101,32,82,101,118,105,101,119,32,81,117
,101,115,116,105,111,110,115
Excellent! The "174" character has survived the transfer and is now in place on PRODCLONE.
Now that we have a method to move the data over, we have to identify which columns /tables have character data that was damaged by the conversion. We decided we could ignore anything with a length smaller than 10 -- such fields in our application would be unlikely to have data with invalid characters.
RESTORECLONE> select count(1) from user_tab_columns where data_type in ('CHAR','VARCHAR2') and data_length > 10;
   COUNT(1)
    533
By converting a field to WE8ISO8859P1, and then comparing it with the original, we can see if the characters change:
RESTORECLONE> select count(1) from my_contents where title != convert (title,'WE8ISO8859P1','US7ASCII') ;
COUNT(1)
     10568
So 10568 rows have characters which were transformed into 191s as part of the original conversion.
[ As an aside, we can't use CONVERT() on LOBs -- for them we will need another approach, outlined further below.
RESTOREDB> select count(1) from my_contents where main_data != convert (convert(main_DATA,'WE8ISO8859P1','US7ASCII'),'US7ASCII','WE8ISO8859P1') ;
select count(1) from my_contents where main_data != convert (convert(main_DATA,'WE8ISO8859P1','US7ASCII'),'US7ASCII','WE8ISO8859P1')
ERROR at line 1:
ORA-00932: inconsistent datatypes: expected - got CLOB
Anyway, now that we can identify VARCHAR2 fields which need to be checked, we can put together a PL/SQL stored procedure to do it for us:
create or replace procedure find_us7_strings
(table_name varchar2,
fix_col varchar2 )
authid current_user
as
orig_sql varchar2(1000);
begin
orig_sql:='insert into cnv_us7(mytablename,myindx,mycolumnname) select '''||table_name||''',pk1,'''||fix_col||''' from '||table_name||' where '||fix_col||' != CONVERT(CONVERT('||fix_col||',''WE8ISO8859P1''),''US7ASCII'') and '||fix_col||' is not null';
-- Uncomment if debugging:
-- dbms_output.put_line(orig_sql);
execute immediate orig_sql;
end;
And create a table to store the information as to which tables, columns, and rows have the bad characters:
drop table cnv_us7;
create table cnv_us7 (mytablename varchar2(50), myindx number,      mycolumnname varchar2(50) ) tablespace myuser_data;
create index list_tablename_idx on cnv_us7(mytablename) tablespace myuser_indx;
With a SQL-generating SQL script, we can iterate through all the tables/columns we want to check:
--example of using the data: select title from my_contents where pk1 in (select myindx from cnv_us7)
set head off pagesize 1000 linesize 120
spool runme.sql
select 'exec find_us7_strings ('''||table_name||''','''||column_name||'''); ' from user_tab_columns
      where
          data_type in ('CHAR','VARCHAR2')
          and table_name in (select table_name from user_tab_columns where column_name='PK1' and table_name not in ('HUGETABLEIWANTTOEXCLUDE','ANOTHERTABLE'))
          and char_length > 10
          order by table_name,column_name;
spool off;
set echo on time on timing on feedb on serveroutput on;
spool output_of_runme
@./runme.sql
spool off;
Which eventually gives us the following inserted into CNV_US7:
20:48:21 SQL> select count(1),mycolumnname,mytablename from cnv_us7 group by mytablename,mycolumnname;
         4 DESCRIPTION                                        MY_FORUMS
     21136 TITLE                                              MY_CONTENTS
Out of 533 VARCHAR2s and CHARs, we only had five or six columns that needed fixing
We create our views on RESTOREDB:
create or replace view my_forums_vv as select pk1,utl_raw.cast_to_raw(description) as description from forum_main;
create or replace view my_contents_vv as select pk1,utl_raw.cast_to_raw(title) as title from my_contents;
And then we can fix it directly via sql:
update my_contents taborig1 set TITLE= (select utl_raw.cast_to_varchar2 (TITLE) from my_contents_vv@old6 where pk1=taborig1.pk1)
where pk1 in (
select tabnew.pk1 from my_contents@old6 taborig,my_contents tabnew,cnv_us7@old6
      where taborig.pk1=tabnew.pk1
          and myindx=tabnew.pk1
          and mycolumnname='TITLE'
          and mytablename='MY_CONTENTS'
          and convert(taborig.TITLE,'US7ASCII','WE8ISO8859P1') = tabnew.TITLE );
Note this part:
      "and convert(taborig.TITLE,'US7ASCII','WE8ISO8859P1') = tabnew.TITLE "
This checks to verify that the TITLE field on the PRODCLONE and RESTORECLONE are the same (barring character set issues). This is there because if the users have changed TITLE -- or any other field -- on their own between the time of the upgrade and now, we do not want to overwrite their changes. We make the assumption that as part of the process, they may have changed the bad character on their own.
We can also create a stored procedure which will execute the SQL for us:
create or replace procedure fix_us7_strings
(TABLE_NAME varchar2,
FIX_COL varchar2 )
authid current_user
as
orig_sql varchar2(1000);
TYPE cv_type IS REF CURSOR;
orig_cur cv_type;
begin
orig_sql:='update '||TABLE_NAME||' taborig1 set '||FIX_COL||'= (select utl_raw.cast_to_varchar2 ('||FIX_COL||') from '||TABLE_NAME||'_vv@old6 where pk1=taborig1.pk1)
where pk1 in (
select tabnew.pk1 from '||TABLE_NAME||'@old6 taborig,'||TABLE_NAME||' tabnew,cnv_us7@old6
      where taborig.pk1=tabnew.pk1
          and myindx=tabnew.pk1
          and mycolumnname='''||FIX_COL||'''
          and mytablename='''||TABLE_NAME||'''
          and convert(taborig.'||FIX_COL||',''US7ASCII'',''WE8ISO8859P1'') = tabnew.'||FIX_COL||')';
dbms_output.put_line(orig_sql);
execute immediate orig_sql;
end;
exec fix_us7_strings('MY_FORUMS','DESCRIPTION');
exec fix_us7_strings('MY_CONTENTS','TITLE');
commit;
To validate this before and after, we can run something like:
select dump(description) from my_forums where pk1 in (select myindx from cnv_us7@old6 where mytablename='MY_FORUMS');
The above process fixes all the VARCHAR2s and CHARs. Now what about the CLOB columns?
Note that we're going to have some extra difficulty here, not just because we are dealing with CLOBs, but because we are working with CLOBs in 9i, whose functions have less CLOB-related functionality.
This procedure finds invalid US7ASCII strings inside a CLOB in 9i:
create or replace procedure find_us7_clob
(table_name varchar2,
fix_col varchar2)
authid current_user
as
orig_sql varchar2(1000);
type cv_type is REF CURSOR;
orig_table_cur cv_type;
my_chars_read NUMBER;
my_offset NUMBER;
my_problem NUMBER;
my_lob_size NUMBER;
my_indx_var NUMBER;
my_total_chars_read NUMBER;
my_output_chunk VARCHAR2(4000);
my_problem_flag NUMBER;
my_clob CLOB;
my_total_problems NUMBER;
ins_sql VARCHAR2(4000);
BEGIN
   DBMS_OUTPUT.ENABLE(1000000);
   orig_sql:='select pk1,dbms_lob.getlength('||FIX_COL||') as cloblength,'||fix_col||' from '||table_name||' where dbms_lob.getlength('||fix_col||') >0 and '||fix_col||' is not null order by pk1';
   open orig_table_cur for orig_sql;
   my_total_problems := 0;
   LOOP
        FETCH orig_table_cur INTO my_indx_var,my_lob_size,my_clob;
                EXIT WHEN orig_table_cur%NOTFOUND;
        my_offset :=1;
        my_chars_read := 512;
        my_problem_flag :=0;
        WHILE my_offset < my_lob_size and my_problem_flag =0
                LOOP
                DBMS_LOB.READ(my_clob,my_chars_read,my_offset,my_output_chunk);
                my_offset := my_offset + my_chars_read;
                IF my_output_chunk != CONVERT(CONVERT(my_output_chunk,'WE8ISO8859P1'),'US7ASCII')
                        THEN
                        -- DBMS_OUTPUT.PUT_LINE('Problem with '||my_indx_var);
                        -- DBMS_OUTPUT.PUT_LINE(my_output_chunk);
                        my_problem_flag:=1;
                END IF;
        END LOOP;
        IF my_problem_flag=1
                THEN my_total_problems := my_total_problems +1;
                ins_sql:='insert into cnv_us7(mytablename,myindx,mycolumnname) values ('''||table_name||''','||my_indx_var||','''||fix_col||''')';
                execute immediate ins_sql;
                END IF;
   END LOOP;
   DBMS_OUTPUT.PUT_LINE('We found '||my_total_problems||' problem rows in table '||table_name||', column '||fix_col||'.');
END;
And we can use SQL-generating SQL to find out which CLOBs have issues, out of all the ones in the database:
RESTOREDB> select 'exec find_us7_clob('''||table_name||''','''||column_name||''');' from user_tab_columns where data_type='CLOB';
exec find_us7_clob('MY_CONTENTS','DATA');
After completion, the CNV_US7 table looked like this:
RESTOREDB> set linesize 120 pagesize 100;
RESTOREDB> select count(1),mytablename,mycolumnname from cnv_us7
   where mytablename||' '||mycolumnname in (select table_name||' '||column_name from user_tab_columns
         where data_type='CLOB' )
      group by mytablename,mycolumnname;
COUNT(1) MYTABLENAME                                        MYCOLUMNNAME
     69703 MY_CONTENTS                                  DATA
On RESTOREDB, our 9i version, we will use this procedure (found many years ago on the internet):
create or replace procedure CLOB2BLOB (p_clob in out nocopy clob, p_blob in out nocopy blob) is
-- transforming CLOB to BLOB
l_off number default 1;
l_amt number default 4096;
l_offWrite number default 1;
l_amtWrite number;
l_str varchar2(4096 char);
begin
loop
dbms_lob.read ( p_clob, l_amt, l_off, l_str );
l_amtWrite := utl_raw.length ( utl_raw.cast_to_raw( l_str) );
dbms_lob.write( p_blob, l_amtWrite, l_offWrite,
utl_raw.cast_to_raw( l_str ) );
l_offWrite := l_offWrite + l_amtWrite;
l_off := l_off + l_amt;
l_amt := 4096;
end loop;
exception
when no_data_found then
NULL;
end;
We can test out the transformation of CLOBs to BLOBs with a single row like this:
drop table my_contents_lob;
Create table my_contents_lob (pk1 number,data blob);
DECLARE
      v_clob CLOB;
      v_blob BLOB;
    BEGIN
      SELECT data INTO v_clob FROM my_contents WHERE pk1 = 16 ;
      INSERT INTO my_contents_lob (pk1,data) VALUES (16,empty_blob() );
      SELECT data INTO v_blob FROM my_contents_lob WHERE pk1=16 FOR UPDATE;
      clob2blob (v_clob, v_blob);
    END;
select dbms_lob.getlength(data) from my_contents_lob;
DBMS_LOB.GETLENGTH(DATA)
                             329
SQL> select utl_raw.cast_to_varchar2(data) from my_contents_lob;
UTL_RAW.CAST_TO_VARCHAR2(DATA)
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam...
Now we need to push it through a loop. Unfortunately, I had trouble making the "SELECT INTO" dynamic. Thus I used a version of the procedure for each table. It's aesthetically displeasing, but at least it worked.
create table my_contents_lob(pk1 number,data blob);
create index my_contents_lob_pk1 on my_contents_lob(pk1) tablespace my_user_indx;
create or replace procedure blob_conversion_my_contents
(table_name varchar2,
fix_col varchar2)
authid current_user
as
orig_sql varchar2(1000);
type cv_type is REF CURSOR;
orig_table_cur cv_type;
my_chars_read NUMBER;
my_offset NUMBER;
my_problem NUMBER;
my_lob_size NUMBER;
my_indx_var NUMBER;
my_total_chars_read NUMBER;
my_output_chunk VARCHAR2(4000);
my_problem_flag NUMBER;
my_clob CLOB;
my_blob BLOB;
my_total_problems NUMBER;
new_sql VARCHAR2(4000);
BEGIN
DBMS_OUTPUT.ENABLE(1000000);
   orig_sql:='select pk1,dbms_lob.getlength('||FIX_COL||') as cloblength,'||fix_col||' from '||table_name||' where pk1 in (select myindx from cnv_us7 where mytablename='''||TABLE_NAME||''' and mycolumnname='''||FIX_COL||''') order by pk1';
   open orig_table_cur for orig_sql;
   LOOP
        FETCH orig_table_cur INTO my_indx_var,my_lob_size,my_clob;
                EXIT WHEN orig_table_cur%NOTFOUND;
        new_sql:='INSERT INTO '||table_name||'_lob(pk1,'||fix_col||') values ('||my_indx_var||',empty_blob() )';
        dbms_output.put_line(new_sql);
      execute immediate new_sql;
-- Here's the bit that I had trouble making dynamic. Feel free to let me know what I am doing wrong.
-- new_sql:='SELECT '||fix_col||' INTO my_blob from '||table_name||'_lob where pk1='||my_indx_var||' FOR UPDATE';
--        dbms_output.put_line(new_sql);
        select data into my_blob from my_contents_lob where pk1=my_indx_var FOR UPDATE;
      clob2blob(my_clob,my_blob);
   END LOOP;
   CLOSE orig_table_cur;
DBMS_OUTPUT.PUT_LINE('Completed program');
END;
exec blob_conversion_my_contents('MY_CONTENTS','DATA');
Verify that things work properly:
select dump( utl_raw.cast_to_varchar2(data)) from my_contents_lob where pk1=xxxx;
This should let you see see characters > 150. Thus, the method works.
We can now take this data, export it from RESTORECLONE
exp file=a.dmp buffer=4000000 userid=system/XXXXXX tables=my_user.my_contents rows=y
and import the data on prodclone
imp file=a.dmp fromuser=my_user touser=my_user userid=system/XXXXXX buffer=4000000;
For paranoia's sake, double check that it worked properly:
select dump( utl_raw.cast_to_varchar2(data)) from my_contents_lob;
On our 10g PRODCLONE, we'll use these stored procedures:
CREATE OR REPLACE FUNCTION CLOB2BLOB(L_CLOB CLOB) RETURN BLOB IS
L_BLOB BLOB;
L_SRC_OFFSET NUMBER;
L_DEST_OFFSET NUMBER;
L_BLOB_CSID NUMBER := DBMS_LOB.DEFAULT_CSID;
V_LANG_CONTEXT NUMBER := DBMS_LOB.DEFAULT_LANG_CTX;
L_WARNING NUMBER;
L_AMOUNT NUMBER;
BEGIN
DBMS_LOB.CREATETEMPORARY(L_BLOB, TRUE);
L_SRC_OFFSET := 1;
L_DEST_OFFSET := 1;
L_AMOUNT := DBMS_LOB.GETLENGTH(L_CLOB);
DBMS_LOB.CONVERTTOBLOB(L_BLOB,
L_CLOB,
L_AMOUNT,
L_SRC_OFFSET,
L_DEST_OFFSET,
1,
V_LANG_CONTEXT,
L_WARNING);
RETURN L_BLOB;
END;
CREATE OR REPLACE FUNCTION BLOB2CLOB(L_BLOB BLOB) RETURN CLOB IS
L_CLOB CLOB;
L_SRC_OFFSET NUMBER;
L_DEST_OFFSET NUMBER;
L_BLOB_CSID NUMBER := DBMS_LOB.DEFAULT_CSID;
V_LANG_CONTEXT NUMBER := DBMS_LOB.DEFAULT_LANG_CTX;
L_WARNING NUMBER;
L_AMOUNT NUMBER;
BEGIN
DBMS_LOB.CREATETEMPORARY(L_CLOB, TRUE);
L_SRC_OFFSET := 1;
L_DEST_OFFSET := 1;
L_AMOUNT := DBMS_LOB.GETLENGTH(L_BLOB);
DBMS_LOB.CONVERTTOCLOB(L_CLOB,
L_BLOB,
L_AMOUNT,
L_SRC_OFFSET,
L_DEST_OFFSET,
1,
V_LANG_CONTEXT,
L_WARNING);
RETURN L_CLOB;
END;
And now, for the piece de' resistance, we need a BLOB to CLOB conversion that assumes that the BLOB data is stored initially in WE8ISO8859P1.
To find correct CSID for WE8ISO8859P1, we can use this query:
select nls_charset_id('WE8ISO8859P1') from dual;
Gives "31"
create or replace FUNCTION BLOB2CLOBASC(L_BLOB BLOB) RETURN CLOB IS
L_CLOB CLOB;
L_SRC_OFFSET NUMBER;
L_DEST_OFFSET NUMBER;
L_BLOB_CSID NUMBER := 31;      -- treat blob as WE8ISO8859P1
V_LANG_CONTEXT NUMBER := 31;   -- treat resulting clob as WE8ISO8850P1
L_WARNING NUMBER;
L_AMOUNT NUMBER;
BEGIN
DBMS_LOB.CREATETEMPORARY(L_CLOB, TRUE);
L_SRC_OFFSET := 1;
L_DEST_OFFSET := 1;
L_AMOUNT := DBMS_LOB.GETLENGTH(L_BLOB);
DBMS_LOB.CONVERTTOCLOB(L_CLOB,
L_BLOB,
L_AMOUNT,
L_SRC_OFFSET,
L_DEST_OFFSET,
L_BLOB_CSID,
V_LANG_CONTEXT,
L_WARNING);
RETURN L_CLOB;
END;
select dump(dbms_lob.substr(blob2clobasc(data),4000,1)) from my_contents_lob;
Now, we can compare these:
select dbms_lob.compare(blob2clob(old.data),new.data) from my_contents new,my_contents_lob old where new.pk1=old.pk1;
DBMS_LOB.COMPARE(BLOB2CLOB(OLD.DATA),NEW.DATA)
                                                             0
                                                             0
                                                             0
Vs
select dbms_lob.compare(blob2clobasc(old.data),new.data) from my_contents new,my_contents_lob old where new.pk1=old.pk1;
DBMS_LOB.COMPARE(BLOB2CLOBASC(OLD.DATA),NEW.DATA)
                                                               -1
                                                               -1
                                                               -1
update my_contents a set data=(select blob2clobasc(data) from my_contents_lob b where a.pk1= b.pk1)
    where pk1 in (select al.pk1 from my_contents_lob al where dbms_lob.compare(blob2clob(al.data),a.data) =0 );
SQL> select dump(dbms_lob.substr(data,4000,1)) from my_contents where pk1 in (select pk1 from my_contents_lob);
Confirms that we're now working properly.
To run across all the _LOB tables we've created:
[oracle@RESTORECLONE ~]$ exp file=all_fixed_lobs.dmp buffer=4000000 userid=my_user/mypass tables=MY_CONTENTS_LOB,MY_FORUM_LOB...
[oracle@RESTORECLONE ~]$ scp all_fixed_lobs.dmp jboulier@PRODCLONE:/tmp
And then on PRODCLONE we can import:
imp file=all_fixed_lobs.dmp buffer=4000000 userid=system/XXXXXXX fromuser=my_user touser=my_user
Instead of running the above update statement for all the affected tables, we can use a simple stored procedure:
create or replace procedure fix_us7_CLOBS
(TABLE_NAME varchar2,
     FIX_COL varchar2 )
    authid current_user
    as
     orig_sql varchar2(1000);
     bak_sql varchar2(1000);
    begin
    dbms_output.put_line('Creating '||TABLE_NAME||'_PRECONV to preserve the original data in the table');
    bak_sql:='create table '||TABLE_NAME||'_preconv as select pk1,'||FIX_COL||' from '||TABLE_NAME||' where pk1 in (select pk1 from '||TABLE_NAME||'_LOB) ';
    execute immediate bak_sql;
    orig_sql:='update '||TABLE_NAME||' tabnew set '||FIX_COL||'= (select blob2clobasc ('||FIX_COL||') from '||TABLE_NAME||'_LOB taborig where tabnew.pk1=taborig.pk1)
   where pk1 in (
   select a.pk1 from '||TABLE_NAME||'_LOB a,'||TABLE_NAME||' b
      where a.pk1=b.pk1
             and dbms_lob.compare(blob2clob(a.'||FIX_COL||'),b.'||FIX_COL||') = 0 )';
    -- dbms_output.put_line(orig_sql);
    execute immediate orig_sql;
   end;
Now we can run the procedure and it fixes everything for our previously-broken tables, keeping the changed rows -- just in case -- in a table called table_name_PRECONV.
set serveroutput on time on timing on;
exec fix_us7_clobs('MY_CONTENTS','DATA');
commit;
After confirming with the client that the changes work -- and haven't noticeably broken anything else -- the same routines can be carefully run against the actual production database.

We converted using the database using scripts I developed. I'm not quite sure how we converted is relevant, other than saying that we did not use the Oracle conversion utility (not csscan, but the GUI Java tool).
A summary:
1) We replaced the lossy characters by parsing a csscan output file
2) After re-scanning with csscan and coming up clean, our DBA converted the database to AL32UTF8 (changed the parameter file, changing the character set, switched the semantics to char, etc).
3) Final step was changing existing tables to use char semantics by changing the table schema for VARCHAR2 columns
Any specific steps I cannot easily answer, I worked with a DBA at our company to do this work. I handled the character replacement / DDL changes and the DBA ran csscan & performed the database config changes.
Our actual error message:
ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00210: expected '<' instead of '�Error at line 1
31011. 00000 - "XML parsing failed"
*Cause:    XML parser returned an error while trying to parse the document.
*Action:   Check if the document to be parsed is valid.
Error at Line: 24 Column: 15
This seems to match the the document ID referenced below. I will ask our DBA to pull it up and review it.
Please advise if more information is needed from my end.

Matching across multiple character sets

Would like to know whether anyone has attempted matching across multiple character sets, for example, between English and Japanese: what are the pitfalls to avoid, what are the best practices, and what you would like to see from application/tools perspective as an ideal solution. thanks

If you upgrade to Logic Pro, you'll get WaveBurner as part of the package which helps you do this, including tweaking your pauses between tracks, fades etc.
If you have Toast, you can do it there too.
If you don't have any 3rd. party software, the work around would be to assemble all your songs in order, end to end in a new Logic file, and listen to all your tracks and adjust the relative levels between songs, then bounce out the individual tracks which have volume changes with their new volume settings. Finally you could then use any burning app such as [SimplyBurns|http://bit.ly/c1oglP] to create CDs or bounce them out in Logic with the additional .mp3 option.
Obviously it's important to listen to your material in order, in context, as some songs will be at the wrong subjective level depending on the tracks either side in the placement. This isn't really important in digital distribution where your material probably won't be listened to as a whole, but as individual downloads.

Foreign character sets in a database

I am developing a site where people in many countries (mainly
Scandinavian) can log on and update their pages. The information,
(including passwords and usernames) is stored in an access
database. I am using Access because I have no knowledge of PHP /
SQL, and the site is unlikely to exceed the limitations of Access
for a few years.
Does Access change the format of text, or do I have to set up
some special encoding? I find that if I type in the username and
password using an english keyboard, when the original was set up
using a foreign keyboard I cannot log in. The reverse also applies.
I am using CS3 in default mode - using utf8. Should I be using
Westren European encoding, or is Access the fly in the ointment?
Or is it likely to be another problem.
Howard Walker

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

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

How to change character set to arabic in Develper suite forms 10g

Dear all,
Our company wants migrate oracle forms 4.5/6i applications to Oracle developer suite 10g version.
They also want there database to upgrade from 9i to 10g.
They gave me test machine, on which windows xp is installed and i did the following:-
1,Installed Oracle 10g Xe edition database.
2,Installed Oracle 10g Devloper suite(oracle forms, Oracle reports).
3, Configured the connection of Oracle Developer suite 10g to Oracle Database 10g.
4, Loaded Data into the 10g database. *( they are few columns like DEPARTMENT_NAME_ARB, FUNCTION_NAME_ARB which is supposed to show in arabic fonts, as it is in arabic in 9i database, now they are showing in some special characters)*
What I would like to know is: Is there a way through which i can set characterset?
Is it in the database in which i have to make character set change?
Is it in the oracle developer suite application in which i have to make character set change?
Is it in the registry in which i have to make changes?
please help.

Hi freinds,
It is very encouraging to see your replies, i apologize for the late reponse, i still got no success with updating PROPS$,
I relgiously followed all the instructions given to me by all of you. Like u could see in my previous posts
Luckiily, i am able to insert one row at a time manaually iin arabic and in english by pressing (ALT+SHIFT).
When i create datablocks in forms builder, i do see output in arabic.
When i create report in group style i do see ouptput in arabic.
i have thousands of rows(in GB's) which needs to be inserted in this new database 10g XE edition (downloaded from oracle)
I have attempted multiple times insertion of data by just running script, or simply copying numerous insert statement rows from notepad to sql*plus, unluckily it alwayz retreived the special charachters rather than retreiving arabic characters.
Is there a way to insert data in this new oracle 10g xe editon database via oracle developer suite 10g forms/reports?
Do I have to use inbuilt data load/unload utilities in oracle 10g xe edition?
Do I have to install sql*loader separately to load the data?
Do you think TOAD can help in this?
Could you please tell me how to add snap shots in this post?(user10947262)
Here are the following details of National Language Parameter Value
Before
NLS_CALENDAR     GREGORIAN
NLS_CHARACTERSET     AL32UTF8 (IS this multibyte (UTF-8) character set SARAH?)
NLS_COMP     BINARY
NLS_CURRENCY     $
NLS_DATE_FORMAT     DD-MON-RR
NLS_DATE_LANGUAGE     AMERICAN
NLS_DUAL_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_LANGUAGE     AMERICAN
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NUMERIC_CHARACTERS     .,
NLS_SORT     BINARY
NLS_TERRITORY     AMERICA
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
After
NLS_CALENDAR     GREGORIAN
NLS_CHARACTERSET     AL32UTF8
NLS_COMP     BINARY
NLS_CURRENCY     ر.س.
NLS_DATE_FORMAT     DD/MM/RR
NLS_DATE_LANGUAGE     ARABIC
NLS_DUAL_CURRENCY     ر.س.
NLS_ISO_CURRENCY     SAUDI ARABIA
NLS_LANGUAGE     ARABIC
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NUMERIC_CHARACTERS     .,
NLS_SORT     ARABIC
NLS_TERRITORY     SAUDI ARABIA
NLS_TIME_FORMAT     HH12:MI:SSXFF PM
NLS_TIMESTAMP_FORMAT     DD/MM/RR HH12:MI:SSXFF PM
NLS_TIMESTAMP_TZ_FORMAT     DD/MM/RR HH12:MI:SSXFF PM TZR
NLS_TIME_TZ_FORMAT     HH12:MI:SSXFF PM TZR
Certainly Christian, i dont want to screw my oracle 10g database xe edition software and installation, and i agree and hope with this that creating new database and doing exporting and importing will work for me. (XE edition doesnt give option to create new database, i need to install 10g release2 media pack from edelivery)
However, with the above informatiion provided, Is it really needed?
Please help me.
Thanks and Regards

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 Set based on Logon Language

Hi expert,
We have an issue here after upgrade from ECC5 to ECC6.
- In ECC5 (non-unicode), if we login with language ZH (chinese), the character set automatic set to Simplified Chinese.
- In ECC6(unicode), if we login with language ZH (chinese), the character set remain be Western European.
How can we set the system to automatic set the correct character set based on user logon language?
Currently in ECC6, user have to go to application toolbar -> Customize Local Layout -> Character Set to select the correct character set.
Any advice will be very appreciate.
Thank you.

Hi,
Does someone has any idea on my issue?
Thank you.

Upgrade to 5.0.2 - Character Sets?

Similar Messages

Maybe you are looking for