CLOB WE8ISO8859P1 to AL32UTF8

I got a CLOB filled from the file system with XML Content, which should be UTF8 but for some strange reasons the XML file generated is in WE8ISO8859P1. As I want to insert the XML File on an XML Table I have to convert the incoming clob data into UTF8 before the insert can happen.
Here's the error message I get on insert:
ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00217: invalid character 26 (U+001A)
Error at line 490356
I googled for a while now and it's easy to achieve this with CONVERT for varchar2, but I don't know how this can work out for clobs. Any help appreciated.

"Lossy conversion" means that some character codes (bytes) in the listed CLOBs are not recognized as valid in WE8ISO8859P1. These codes are usually in the range 0x80-0x9f. You need to take a look at these codes and try to guess what their real meaning is. In most cases that Oracle customers encounter, these illegal WE8ISO8859P1 codes are in reality WE8MSWIN1252 codes (WE8MSWIN1252 is a binary superset of WE8ISO8859P1). The solution is then to fix the source database character set to the right character set and then export.
Thanks,
Sergiusz

Similar Messages

Characterset change from WE8ISO8859P1 to AL32UTF8

Hi,
I have restore the rman on new server oracle 11.2.0.3 (Previous backup was of oracle 10.2.0.4).
Then I have successfully upgrade the database to oracle 11g but issue which I am facing right now is that the old database have the character set WE8ISO8859P1 which is now upgraded to oracle 11.2.0.3 database server.
My required character set is AL32UTF32.
Now is there any way that while restoring the rman backup of oracle 10.2.0.4 on new server I set the character set to AL32UTF32.
Thank you for your cooperation.
Kind Regards,
Adnan Hamdussalam

It means that either I have to change it before backup or after perform the full upgrade on new server oracle 11g and then convert the character set. Am I right?Yes, You are right.
I think as you are changing from WE8ISO8859P1 to AL32UTF8, so you do not need any tool.
Must read note,
*Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) [ID 260192.1]*

PlsqlNLSLanguage WE8ISO8859P1 vs AL32UTF8

Hi,
I upgraded to 3.0.1 and I am having some issues with apostrophe when I switch the PlsqlNLSLanguage from WE8ISO8859P1 to AL32UTF8.
I did run the OWAINST script to upgrade Web Toolkit.
So my pages displays correctly except for those apostrophe that shows as little squares.
If I use WE8ISO8859P1 , everything displays and inserts correctly. Why can't I keep this setting for PlsqlNLSLanguage ?
If I use AL32UTF8 , when I insert, the apostrophe shows as reversed questionmarks ( de l¿AQIII ). When I select apostrophe inserted in WE8ISO8859P1 , it shows as little boxes. (de l�AQIII )
I am kind of stuck with this.
Anybody experiencing this behaviour ?
Normal apostrophe works, it's when I cut and paste from Word that it does not inserts correctly.
I am using APEX 3.0.1
OWA 10.1.2.0.6
DB : 10.1.0.5.0
DB Characterset : WE8ISO8859P1
Thanks
Francis.

Hi Francis,
Thanks for explaining this and thanks for including the information in #4. You have stated precisely your issue.
The fundamental problem is you are attempting to include the MS Word-generated apostophe, in your data. This character is known as RIGHT SINGLE QUOTATION MARK, Unicode character U+2019, AL32UTF8 codepoint E28099. There is no equivalent codepoint in your database character set, WE8ISO8859P1 which can accommodate this character.
Of course, you're going to ask, why wasn't this a problem before? And that's because in HTML DB 1.6 and earlier, when the database character set matched the DAD character set, no character set conversion was attempted. So even though the character couldn't directly be accommodated in WE8ISO8859P1, the bytes were stored as is.
Now, in HTML DB 2.0 and APEX 3.0 and later, the DAD character set must be AL32UTF8. So there will be character set conversion between mod_plsql and your database - on data going into the database and data coming out of the database.
Unfortunately, the DAD character set must be AL32UTF8 in APEX 3.0 - otherwise, you'll run into trouble later - guaranteed. The only viable solution for you, as I see it, is either change your database character set to AL32UTF8 or somehow avoid entering these characters.
I hope this helps.
Joel

WE8ISO8859P1 to AL32UTF8

Earlier I was having WE8ISO8859P1 as character set .
Now database has been upgraded to AL32UTF8.
The below query was giving 158 characters earlier .On AL32UTF8 its just giving 30 characters.
Can you please help me where should I change the query to get special characters with ascii value between 1 to 31 or ascii value greater than 126.
SELECT REPLACE
(REPLACE (MAX (REPLACE (SYS_CONNECT_BY_PATH (ch, ' '),
CHR (10),
CHR (13),
) chars
FROM (SELECT CASE
WHEN ((LEVEL BETWEEN 1 AND 31) OR (LEVEL > 126)
THEN CHR (LEVEL)
ELSE ('')
END ch,
ROWNUM r
FROM DUAL
CONNECT BY LEVEL <= 255)
START WITH r = 1
CONNECT BY PRIOR r + 1 = r
Thanks.

As you've changed to a multi-byte character set on your database, you'll find lots of issues with things like this.
You'll probably want to change that query to use NCHR instead of CHR to account for the character set being used.
http://docs.oracle.com/cd/E11882_01/server.112/e26088/functions104.htm#SQLRF00670

WE8ISO8859P1 to AL32UTF8, error on some characters

Hello!
We're moving from 9i WE8ISO8859P1 to 11g AL32UTF8.
We've checked the sizes of all columns and recreated the tables and such to hold all the new data (since it will be larger than before for som rows).
But we have a, quite small, but possible big problem:
We find that 2 characters are converted from the source to the destination character set wrongly. Possible more characters, but only 2 identified so far.
Everyone working with AL32UTF8 knows that the regular ASCII characters below code 127 remans at this decimal code in AL32UTF8. And other (>127) are moved into different UTF-8 character groups (either, 2, 3 or 4 bytes long).
Most of our "special" characters, that mainly consist of the swedish auml-characters (åäö ÅÄÖ) are moves correctly, together with other special characters. The resulting AL32UTF8 database shows them correctly.
But 2 characters; the "–" (em-dash, long -) and the "”" (right double qutation mark) gets converted to characters with decimal code 49814 and 49812. This shows up as error/unknown characters when output.
After some research I find that the correct values for these two are in fact 14846098 and 14844061, and when replaced in the database - REPLACE(s, CHR(49812), CHR(14846098)) - everything shows up as OK when output from the database.
Why is this? Is there anyone else experiencing the same problem? What other characters could be in the same, wrongly converted, group?
By the way, I've tried setting the NLS_LANG parameter to every possible value (WE8ISO8859P1, AL32UTF8 and UTF8) both when importing and exporting, and every possible combination of these, but with no luck.
Regards
Charlie Elgholm

But 2 characters; the "–" (em-dash, long -) and the
"”" (right double qutation mark) gets converted toAre those Windows-1252 characters? (do you have win-1252 clients/data entry?)
You could verify the source database by using the dump() function, such as
select col, dump(col,1016) from table where...;
I believe ISO 8859-1 does not define en/em-dashes and windows curly quotes.
Why is this? Is there anyone else experiencing the
same problem? What other characters could be in the
same, wrongly converted, group?Could be because of incorrect data stored. The Globalization doc has a chapter on Character Set Migration.
If feasible, look into fixing the data before char set migration.

Which is superset codepage AL32UTF8 or WE8ISO8859P1?

My Souce database character set is AL32UTF8 (11.1.0.7.0)
My target database character set is WE8ISO8859P1 (10.2.0.4)
The oracle BI Aplication installer says:
The code page of the Oracle Business Analytics Warehouse (target) must be a superset of the code page of the source database
so my taget codepage is a superset of my source codepage?
Please confirm
Regards,
DB

No: AL32UTF8 is a superset of WE8ISO8859P1 because AL32UTF8 is Unicode based and not WE8ISO8859P1.
Note that is not a binary superset (every subset character has the same binary encoding in superset) but only a superset
(each subset character exist in the superset but not with the same binary encoding).
Edited by: P. Forstmann on 13 janv. 2011 16:20

Unable to migrate WE8ISO8859P1 to ALUTF8 *Unrecognized convertible date*

Hi
..have followed all steps in migration guide
create CSMIG
take backup (used datapump)
run cs scan
stopped db
startup restrict
run csalter.plbthe script fails with error:
Unrecognized convertible date found in scanner result
database: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
scan output:
scan.err file:
Database Scan Individual Exception Report
[Database Scan Parameters]
Parameter Value
CSSCAN Version v2.1
Instance Name itempl
Database Version 10.2.0.1.0
Scan type Full database
Scan CHAR data? YES
Database character set WE8ISO8859P1
FROMCHAR WE8ISO8859P1
TOCHAR AL32UTF8
Scan NCHAR data? NO
Array fetch buffer size 10240
Number of processes 3
Capture convertible data? NO
[Data Dictionary individual exceptions]
[Application data individual exceptions]
scan.txt:
Database Scan Summary Report
Time Started : 2010-06-20 23:48:40
Time Completed: 2010-06-20 23:50:33
Process ID Time Started Time Completed
1 2010-06-20 23:48:41 2010-06-20 23:50:31
2 2010-06-20 23:48:41 2010-06-20 23:50:31
3 2010-06-20 23:48:43 2010-06-20 23:50:31
[Database Size]
Tablespace Used Free Total Expansion
SYSTEM 488.38M 21.63M 510.00M 984.00K
UNDOTBS1 20.94M 9.06M 30.00M .00K
SYSAUX 349.44M 10.56M 360.00M 9.52M
TEMP .00K .00K .00K .00K
USERS 22.69M 1.06M 23.75M 10.00K
EXAMPLE 68.25M 31.75M 100.00M 3.00K
Total 949.69M 74.06M 1,023.75M 10.50M
The size of the largest CLOB is 1625114 bytes
[Database Scan Parameters]
Parameter Value
CSSCAN Version v2.1
Instance Name itempl
Database Version 10.2.0.1.0
Scan type Full database
Scan CHAR data? YES
Database character set WE8ISO8859P1
FROMCHAR WE8ISO8859P1
TOCHAR AL32UTF8
Scan NCHAR data? NO
Array fetch buffer size 10240
Number of processes 3
Capture convertible data? NO
[Scan Summary]
All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 2,983,218 0 0 0
CHAR 1,097 0 0 0
LONG 149,525 0 0 0
CLOB 31,468 2,071 0 0
VARRAY 22,366 0 0 0
Total 3,187,674 2,071 0 0
Total in percentage 99.935% 0.065% 0.000% 0.000%
The data dictionary can be safely migrated using the CSALTER script
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 1,730,333 1,465 0 0
CHAR 59,586 0 0 0
LONG 0 0 0 0
CLOB 41 12 0 0
VARRAY 2,019 0 0 0
Total 1,791,979 1,477 0 0
Total in percentage 99.918% 0.082% 0.000% 0.000%
[Distribution of Convertible, Truncated and Lossy Data by Table]
USER.TABLE Convertible Truncation Lossy
ITEMPLDB.EMP 1 0 0
MDSYS.SDO_COORD_OP_PARAM_VALS 200 0 0
MDSYS.SDO_GEOR_XMLSCHEMA_TABLE 1 0 0
MDSYS.SDO_STYLES_TABLE 78 0 0
MDSYS.SDO_XML_SCHEMAS 4 0 0
OE.WAREHOUSES 4 0 0
PM.PRINT_MEDIA 8 0 0
SYS.EXPIMP_TTS_CT$ 8 0 0
SYS.EXTERNAL_TAB$ 1 0 0
SYS.METASTYLESHEET 80 0 0
SYS.RULE$ 4 0 0
SYS.WRH$_SQLTEXT 607 0 0
SYS.WRH$_SQL_PLAN 532 0 0
SYS.WRI$_ADV_ACTIONS 22 0 0
SYS.WRI$_ADV_OBJECTS 418 0 0
SYS.WRI$_ADV_RATIONALE 7 0 0
SYS.WRI$_DBU_FEATURE_METADATA 90 0 0
SYS.WRI$_DBU_FEATURE_USAGE 2 0 0
SYS.WRI$_DBU_HWM_METADATA 17 0 0
SYSMAN.MGMT_HC_OS_COMPONENTS 8 0 0
SYSMAN.MGMT_HC_VENDOR_SW_COMPONENTS 8 0 0
[Distribution of Convertible, Truncated and Lossy Data by Column]
USER.TABLE|COLUMN Convertible Truncation Lossy
ITEMPLDB.EMP|ENAME 1 0 0
MDSYS.SDO_COORD_OP_PARAM_VALS|PARAM_VALUE_FILE 200 0 0
MDSYS.SDO_GEOR_XMLSCHEMA_TABLE|XMLSCHEMA 1 0 0
MDSYS.SDO_STYLES_TABLE|DEFINITION 78 0 0
MDSYS.SDO_XML_SCHEMAS|XMLSCHEMA 4 0 0
OE.WAREHOUSES|SYS_NC00003$ 4 0 0
PM.PRINT_MEDIA|AD_FINALTEXT 4 0 0
PM.PRINT_MEDIA|AD_SOURCETEXT 4 0 0
SYS.EXPIMP_TTS_CT$|XMLINFO 8 0 0
SYS.EXTERNAL_TAB$|PARAM_CLOB 1 0 0
SYS.METASTYLESHEET|STYLESHEET 80 0 0
SYS.RULE$|CONDITION 4 0 0
SYS.WRH$_SQLTEXT|SQL_TEXT 607 0 0
SYS.WRH$_SQL_PLAN|OTHER_XML 532 0 0
SYS.WRI$_ADV_ACTIONS|ATTR5 11 0 0
SYS.WRI$_ADV_ACTIONS|ATTR6 11 0 0
SYS.WRI$_ADV_OBJECTS|ATTR4 418 0 0
SYS.WRI$_ADV_RATIONALE|ATTR5 7 0 0
SYS.WRI$_DBU_FEATURE_METADATA|INST_CHK_LOGIC 11 0 0
SYS.WRI$_DBU_FEATURE_METADATA|USG_DET_LOGIC 79 0 0
SYS.WRI$_DBU_FEATURE_USAGE|FEATURE_INFO 2 0 0
SYS.WRI$_DBU_HWM_METADATA|LOGIC 17 0 0
SYSMAN.MGMT_HC_OS_COMPONENTS|DESCRIPTION 8 0 0
SYSMAN.MGMT_HC_VENDOR_SW_COMPONENTS|DESCRIPTION 8 0 0
[Indexes to be Rebuilt]
USER.INDEX on USER.TABLE(COLUMN)
******* need help..

984437 wrote:
Hi Sergiusz,
I am also into a similar situation. CSALTER results into:
Pl post details of OS and database versions, along with the parameters passed to the csalter utility.
Checking data validity...
Unrecognized convertible data found in scanner result
PL/SQL procedure successfully completed.
Checking or Converting phase did not finish successfully
No database (national) character set will be altered
CSALTER finished unsuccessfully.
After this I tried altering the database character set:
SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8;
Database altered.
This command is undocumented/unsupported and should not be used - it will likely corrupt your database beyond repair - hopefully you have a good backup of the database that you can recover from.
https://forums.oracle.com/forums/search.jspa?threadID=&q=INTERNAL_USE&objID=f50&dateRange=all&userID=&numResults=15
>
Is this a correct way ?
I was able to convert the database character set but I still curious to know if it is the right way to do it.
Any suggestion would be a great help.
Thanks,Also, pl do not hijack an old post - pl post your issue in a new thread.
HTH
Srini

Store Multi Byte Characters in WE8ISO8859P1 Database without Migration

Hi - I am looking for a solution where I can store the Multi Byte Character's under the WE8ISO8859P1 Database.
Below are the DB NLS_PARAMETERS
NLS_CHARACTERSET = WE8ISO8859P1
NLS_NCHAR_CHARACTERSET = AL32UTF8
NLS_LENGTH_SEMANTICS = BYTE
Size of DB = 2 TB.
DB Version = 11.2.0.4
Currently there is a need to store the Chinese Characters under NAME and ADDRESS Columns only. Below are the description of the columns.
Column Name DataType
GIVEN_NAME_ONE
VARCHAR2(120 BYTE)
GIVEN_NAME_TWO
VARCHAR2(120 BYTE)
LAST_NAME
VARCHAR2(120 BYTE)
ADDR_LINE_ONE
VARCHAR2(100 BYTE)
ADDR_LINE_TWO
VARCHAR2(100 BYTE)
ADDR_LINE_THREE
VARCHAR2(100 BYTE)
What are my option's over here without considering the Migration WE8ISO8859P1 DB to AL32UTF8 ?
1. Can I increase the size of the Column i.e make it n x 4. e.g NAME will be 480 Byte and ADDRESS will be 400 Byte.? What are pros and cons ?
2. Convert the existing Column from VARCHAR2 to NVARCHAR2 with the Same Size ? i.e NVARCHAR2(120 BYTE) ?
3. Add the extension to an table with new columns - NVARCHAR2. e.g NAME - NVARCHAR2(120 CHAR) and ADDRESS (100 - CHAR) ?
4. Database got Clobs,Blobs, Long etc. got Varied Data, Is it a good idea to Migrate to AL32UTF8 with Minimal Downtime ?
Please suggest the best alternatives. Thanks.
Thanks
Jitesh

Hi Jitesh,
NLS_NCHAR_CHARACTERSET can either be AL16UTF16 or UTF8. So mostly your DB would have UTF8.
You can definitely insert Unicode characters into N-type columns. Size of the N-type column will depend on the characters you plan to store in them.
If you use N-types, do make sure you use the (N'...') syntax when coding it so that Literals are denoted as being in the national character set by prepending letter 'N'.
Although you can use them, N-types are not very well supported in 3the party client/programming environments, you may need to adapt a lot of code to use N-types properly and there are some limitations.
While at first using N-types for a (few) columns seems like a good idea to avoid the conversion of a whole database , in many cases the end conclusion is that changing the NLS_CHARACTERSET is simply the easiest and fastest way to support more languages in an Oracle database.
So, It depends on how much of your data will be unicode which you would store in N-type characters.
If you do have access to My Oracle Support you can check Note 276914.1 :The National Character Set ( NLS_NCHAR_CHARACTERSET ) in Oracle 9i, 10g , 11g and 12c, For more details.
With respect to your Downtime, The actual conversion (CSALTER or in case using DMU) shouldn't take too much time, if you have run CSSCAN on your DB and made sure you have taken care of all your truncation, convertible and lossy data (if any).
It would be best for you to run CSSCAN initially to gauge how much convertible/lossy/truncation data you need to take care.
$ CSSCAN FROMCHAR=WE8ISO8859P1 TOCHAR=AL32UTF8 LOG=P1TOAl32UTF8 ARRAY=1000000 PROCESS=2 CAPTURE=Y FULL=Y
Regards,
Suntrupth

Error while impdp: ORA-02374: conversion error loading table

Hi,
I am trying to convert the character set from WE8ISO8859P1 to AL32UTF8 using expdp/impdp. for this I first convert WE8ISO8859P1 to WE8MSWIN1252 in source DB to get rid of “lossy” data. I created new database(target) with character set AL32UTF8 and nls_length_semantics = ’CHAR’ and created all the tablespaces as in source DB with auoexend on. I took full export (expdp) of source DB excluding TABLESPACE,STATISTICS,INDEX,CONSTRAINT,REF_CONSTRAINT and imported using impdp to target DB. I found below error in the import log file:
ORA-02374: conversion error loading table "SCTCVT"."SPRADDR_CVT"
ORA-26093: input data column size (44) exceeds the maximum input size (40)
ORA-02372: data for row: CONVERT_STREET_LINE1 : 0X'20202020202020202020202020202020202020202020202020'
I checked with select query on both DBs with below results.
source DB:
04:58:42 SQL> select count(*) from "SCTCVT"."SPRADDR_CVT";
COUNT(*)
74553
target DB:
04:59:24 SQL> select count(*) from "SCTCVT"."SPRADDR_CVT";
COUNT(*)
74552
please suggest me a solution to this.
Thanks and Regards.
Edited by: user12045167 on May 9, 2011 10:39 PM

Thanks for your update maher.
09:15:53 SQL> desc "SCTCVT"."SPRADDR_CVT"
Name Null? Type
SPRADDR_PIDM NUMBER(8)
CONVERT_PIDM VARCHAR2(9 CHAR)
SPRADDR_ATYP_CODE VARCHAR2(2 CHAR)
CONVERT_ATYP_CODE VARCHAR2(2 CHAR)
SPRADDR_SEQNO NUMBER(2)
CONVERT_SEQNO VARCHAR2(2 CHAR)
SPRADDR_FROM_DATE DATE
CONVERT_FROM_DATE VARCHAR2(8 CHAR)
SPRADDR_TO_DATE DATE
CONVERT_TO_DATE VARCHAR2(8 CHAR)
SPRADDR_STREET_LINE1 VARCHAR2(30 CHAR)
CONVERT_STREET_LINE1 VARCHAR2(40 CHAR)
SPRADDR_STREET_LINE2 VARCHAR2(30 CHAR)
CONVERT_STREET_LINE2 VARCHAR2(40 CHAR)
SPRADDR_STREET_LINE3 VARCHAR2(30 CHAR)
CONVERT_STREET_LINE3 VARCHAR2(40 CHAR)
SPRADDR_CITY VARCHAR2(20 CHAR)
CONVERT_CITY VARCHAR2(25 CHAR)
SPRADDR_STAT_CODE VARCHAR2(3 CHAR)
CONVERT_STAT_CODE VARCHAR2(25 CHAR)
SPRADDR_ZIP VARCHAR2(10 CHAR)
CONVERT_ZIP VARCHAR2(15 CHAR)
SPRADDR_CNTY_CODE VARCHAR2(5 CHAR)
CONVERT_CNTY_CODE VARCHAR2(5 CHAR)
SPRADDR_NATN_CODE VARCHAR2(5 CHAR)
CONVERT_NATN_CODE VARCHAR2(5 CHAR)
SPRADDR_PHONE_AREA VARCHAR2(3 CHAR)
CONVERT_PHONE_AREA VARCHAR2(3 CHAR)
SPRADDR_PHONE_NUMBER VARCHAR2(7 CHAR)
CONVERT_PHONE_NUMBER VARCHAR2(7 CHAR)
SPRADDR_PHONE_EXT VARCHAR2(4 CHAR)
CONVERT_PHONE_EXT VARCHAR2(4 CHAR)
SPRADDR_STATUS_IND VARCHAR2(1 CHAR)
CONVERT_STATUS_IND VARCHAR2(1 CHAR)
SPRADDR_ACTIVITY_DATE DATE
CONVERT_ACTIVITY_DATE VARCHAR2(8 CHAR)
SPRADDR_USER VARCHAR2(30 CHAR)
CONVERT_USER VARCHAR2(30 CHAR)
SPRADDR_ASRC_CODE VARCHAR2(4 CHAR)
CONVERT_ASRC_CODE VARCHAR2(4 CHAR)
SPRADDR_DELIVERY_POINT NUMBER(2)
CONVERT_DELIVERY_POINT VARCHAR2(2 CHAR)
SPRADDR_CORRECTION_DIGIT NUMBER(1)
CONVERT_CORRECTION_DIGIT VARCHAR2(1 CHAR)
SPRADDR_CARRIER_ROUTE VARCHAR2(4 CHAR)
CONVERT_CARRIER_ROUTE VARCHAR2(4 CHAR)
SPRADDR_GST_TAX_ID VARCHAR2(15 CHAR)
CONVERT_GST_TAX_ID VARCHAR2(15 CHAR)
SPRADDR_REVIEWED_IND VARCHAR2(1 CHAR)
CONVERT_REVIEWED_IND VARCHAR2(1 CHAR)
SPRADDR_REVIEWED_USER VARCHAR2(30 CHAR)
CONVERT_REVIEWED_USER VARCHAR2(30 CHAR)
SPRADDR_DATA_ORIGIN VARCHAR2(30 CHAR)
CONVERT_DATA_ORIGIN VARCHAR2(30 CHAR)
SPRADDR_CVT_RECORD_ID NUMBER(8)
SPRADDR_CVT_STATUS VARCHAR2(1 CHAR)
SPRADDR_CVT_JOB_ID NUMBER(8)
so here we can see its value is 40 (CONVERT_STREET_LINE1 VARCHAR2(40 CHAR)).
shall i go ahead altering the column?

DB Changed to UTF-8. Now parameter form prompts display in font "symbol"

We are in the process of updating a vendor developed application.
The database character set changed from WE8ISO8859P1 to AL32UTF8.
The vendor supplied reports work fine but our in house developed reports now have an issue with the parameter form font. The parameter font for the prompts is defaulting to "symbol".
This happens even on forms where we have not specified a paper parameter form and
let Oracle generate a default one.
Any ideas on what we need to set to get the parameter form prompts to appear as Courier?
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
Report Builder 10.1.2.3.0
Reports are run from a form. For example:
http://XXX.XXXXX.CA:7777/reports/rwservlet?server=rep_XXX3&envid=XXX8&report=TESTREPORT&destype=CACHE&desformat=PDF&paramform=YES&userid=&recursive_load=no

Hello,
For your problem related the Font Symbol, apply the solution described in the document :
Oracle® Application Server Reports Services Publishing Reports to the Web
10g Release 2 (10.1.2)
B14048-02
18 Implementing Globalization and Bidirectional Support
Repairing Garbled Fonts When Using the WE8ISO8859P15 Character Set
http://download-uk.oracle.com/docs/cd/B14099_17/bi.1012/b14048/pbr_nls.htm#CBJCBCFG
Regards

How to change Database character set?

Hi,
We are planning to make a clone of production Database which has:
select value$ from sys.props$ where name='NLS_CHARACTERSET';
AL32UTF8
We have set up a new server for that purpose and installed database, but by default it has
select value$ from sys.props$ where name='NLS_CHARACTERSET';
WE8ISO8859P1
So after making full import from full backup file we have some broken character in database.
How can I change from WE8ISO8859P1 to AL32UTF8?
I expect that I need to shutdown the clone database or even make from scratch full import.
Thanks

I made a full backup from production database which has AL32UTF8
My new database is fresh and it has WE8ISO8859P1
I think the reason why I'm having some corrupted characters is because of difference in Character set between two database, right?
so I will need to change new database Character set to AL32UTF8 then make again full import.

Changes in application after import- Urgent help!!

Hi All,
We have a QA HTML DB instance and Production HTML DB instance. When we export applications from the QA instance and import it on to the production instance we are seeing some changes in the application. Some of the changes are
1. A popup lov is not getting initialized. Getting the error "Unable to initialize query". The same popup LOV is working in QA instance. Also, if I run the query of the popup LOV in the SQL Command processor of the production instance I am able to see the records.
2. A "blank" entry is getting inserted in the select list. I have not enabled to show NULL value in the attributes of the select list. I cannot see this "blank" entry in QA.
3. Checkboxes in a region are re aligned.
The only difference between the QA and production instance is the characterset. The QA is on WE8ISO8859P1 NLS_CHARACTERSET and production is on AL32UTF8 NLS_CHARACTERSET.
When we export the application we see that it is exported in WE8ISO8859P1, so when we import we have tried both WE8ISO8859P1 and AL32UTF8. But we are still seeing these changes.
Is this change related to the characterset issue? or something else? We cannot change the characterset of the QA instance to AL32UTF8 as of now and if its is character set issue is there a work around?
Any help is appreciated.
Thanks,
Swaroop

Thanks for your reply.
Yes, both databases are running the same version of HTML DB i.e 2.0.0.00.49
Oracle versions are different, QA -10.1.0.3.0, Production - 10.2.0.1.0
The database objects are similar, the schema was exported from QA database and imported on to production database. Data is also same.
-Swaroop

Datapump Network Import from Oracle 10.2.0 to 10.1.0

I have self-developed table bulk copy system based on dmbs_datapump API. It is pretty stable and worked very well for a long time on many servers with oracle 10.1.0. But some days ago we have installed new oracle server with oracle 10.2.0 and have noticed, that our system can't copy tables from new server to another servers. After some time of debugging we got description for our situation... dbms_datapump.open() call is failing with "ORA-39006: internal error" exception. dmbs_dapatump.get_status() returns more detailed description: "ORA-39022: Database version 10.2.0.1.0 is not supported."... We're really disappointed... what we can do to use dbms_datapump.open on 10.1.0 to copy table from 10.2.0?
P.S. We have tried to use different values (COMPATIBLE, LATEST, 10.0.0, 10.1.0) for version parameter of open()... but without luck...
Please, help, because we can't upgrade such many old servers to 10.2.0 and we really need to use this new server...
Thanks in advance,
Alexey Kovyrin

Hello,
Your problem is about the Character Set.
WE8ISO8859P1 stores character in *1* byte but AL32UTF8 (Unicode) uses up to *4* bytes.
So, when you Import from WE8ISO8859P1 to AL32UTF8 you may have the offending error ORA-12899.
To solve it, you may change the option of the Datatype of your column. And choose the option CHAR
instead of BYTE (the default), for instance:
VARCHAR2 (100) --> VARCHAR2(100 CHAR)Then, you could import the data.
You may also change the parameter NLS_LENGTH_SEMANTICS to CHAR.
alter system set nls_length_semantics=char scope=spfile;Then, restart your database.
NB: Although the parameter nls_length_semantics is dynamic you have to restart the database so
that it's taken into account.
Then, you create the Tables (empty) and afterwards you run your Import.
Hope this help.
Best regards,
Jean-Valentin
Edited by: Lubiez Jean-Valentin on Mar 21, 2010 4:26 PM

Full Text Indexing for Arabic using NVARCHAR and NCLOB?

We have an Arabic database that uses UTF-16 and NVARCHAR and NCLOB column types.
The full text indexing of Oracle gives an error saying that it does not support these column types.
Can you please help by telling us what is the workaround for this?

The only workarounds are:
1) Store data in VARCHAR2 and CLOB in a AL32UTF8 database, or
2) Use BLOB for document storage - unfortunately, this may be expensive for a lot of short text
-- Sergiusz

Using CSSCAN to change characterset

Hello... I am looking at changing our 10.2.0.4 database (EE) from WE8ISO8859P1 to AL32UTF8. Because I have a number of "lossy" data records, it appears to me as if the first logical step is to convert (using CSALTER) my database to WE8MSWIN1252 because my CSSCAN from WE8MSWIN1252 to WE8MSWIN1252 shows the "lossy" data items are recognized and no other data records are flagged. (Probably due to those fancy quotation marks Microsoft uses)
But I'm a bit confused about how to take care of the "lossy" data to get CSALTER to allow me to go to WE8MSWIN1252 since I've read that CSALTER won't execute without a "clean" run.
Thanks in advance for your help.

Hi,
Only way to correct the lossydata is idenifying it and correcting it by updating the rows. I am not sure if there any other way. If you proceed without correcting lossy data, you will loose some data or corrupt some data due to conversion.
I believe, csscan does not look at the data in the specifically, but it checks if the existing data will fit in the exiting table columns after conversion due to some charsets being multi byte, it may require them to have bigger column size.
Regards

CLOB WE8ISO8859P1 to AL32UTF8

Similar Messages

Maybe you are looking for