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

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]*

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.

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

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

Install Application error

I have 2 client workspaces 102 (Live) and 105 (Testing) and also have the same thing replicated in my own environment 102 and 105, the idea is that I develop changes in my 105 workspace and export/import into the client 105 for testing and then the client 102 whe testing is complete.
As a quick fix I have developed straight into the clients 105 workspace so that they can see the changes and then ask for any relevant changes.
Today I have finished the development and in preparation for exporting/importing into their 102 workspace I have imported the 105 export into my 102 environment but when i try to install it into my 105 environment I get the error
The application could not be installed because it already exists in different workspace. If you wish to install the application, please do the following:
Remove the existing application from the workspace it currently exists in.
OR
Change the application ID in your export file. An application ID that's currently available you can use is 112.
Upload the changed export file to the repository, and re-install your application.
I have done this before and it is what I want to do, yes it does exist in a different workspace (why does that matter?) I just want this 105 environment to match the client 105 environment, it did install into my 102 workspace OK and I have even taken an export of that newly imported 102 workspace to import into 105 but I get the same error. As I say I have done this before so I don't think it is related to the characterset being set to AL32UTF8
Any ideas?

Yet again my own stupidity
I also have workspace ID 115 and that is what I was trying to import into (in my defence it doesn't specify the ID anywhere just the workspace name) but I have successfully installed it now.
One point to note, my client installation (all workspaces must use the same DAD file) uses PlsqlNLSLanguage "ENGLISH_UNITED KINGDOM.WE8ISO8859P1" as its characterset but my installation uses PlsqlNLSLanguage "ENGLISH_UNITED KINGDOM.AL32UTF8"

HTML DB 10g installation problem on linux HTTP-503 ORA-604

I have a problem after the installation of HTML DB from the linux 10g R2 companion image.
I installed HTML DB and HTTP server in one go, on an new system that only has the default orcl database installed. I run Red Hat enterprise linux on a x86_64 system.
The HTML DB installation took a long time, but gave no errors.
When I access the http://hostname:7777/pls/htmldb url I get an This server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.-error.
But :7777 works fine and give me the http server default page.
In my Apache error log I see the following errors:
[Thu Dec 8 13:28:42 2005] [error] [client 10.11.121.20] [ecid: 1134048522:10.14.66.23:28193:0:1,0] mod_plsql: /pls/htmldb/htmldb HTTP-503 ORA-604
I looked at several internet sources, played with my marvel.conf and my dads.conf but to no avail. My oracle home is different from my html db home. There is no ./network/admin/tnsnames.ora in my HTML_DB _HOME. Should there be? One solution in the faq even told me to copy the htmldb tnsnames.ora over my db tnsnames.ora, but the installation did not create one for me.
When should I use a dads.conf instead of marvel.conf? I don't understand the need for this second file. I tried to also use it, because some solutions and the post-installation instructions hinted on doing it. But then I get a different error in the logs about a double DAD.
When I login through sqlplus in the orcl database with the HTMLDB_PUBLIC_USER and my password (that was created during the installation) it works, but I don't see any tables (yet?). So the account is not locked. But should I see some tables when I do select table_name from user_tables; ?
I probably missing something obvious here, but I'm a bit of a oracle newby.
Any help is appreciated,
Erik

Thanks Diemar,
It worked.
I stopped all oracle process and services.
I then logged out and in again as oracle to see if the unset stuck.
I then started my listener, databases, isqlnet and em.
I then started the httpd with:
${HTMLDB_HOME}/opmn/bin/opmnctl start
opmnctl: opmn started
${HTMLDB_HOME}/opmn/bin/opmnctl startproc
this still gave some errors and the httpd was not started:
ias-component=HTTP_Server
opmnctl: starting opmn managed processes...
================================================================================opmn id=aberlour.uni.mdx.ac.uk:6200
0 of 1 processes started.
ias-instance id=standalone
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ias-component/process-type/process-set:
HTTP_Server/HTTP_Server/HTTP_Server
Error
--> Process (pid=3389)
failed to start a managed process after the maximum retry limit
Log:
/mdx/app/oracle/product/10.2.0/http/opmn/logs/HTTP_Server~1
last lines in this log where:
05/12/08 15:18:50 Stop process
/mdx/app/oracle/product/10.2.0/http/Apache/Apache/bin/apachectl stop: httpd stopped
05/12/08 15:31:55 Start process
/mdx/app/oracle/product/10.2.0/http/Apache/Apache/bin/apachectl start: execing httpd
05/12/08 15:31:57 Start process
/mdx/app/oracle/product/10.2.0/http/Apache/Apache/bin/apachectl start: execing httpd
I then added the PlsqlNLSLanguage line back into the marvel.conf
which now looks:
AddType text/xml xbl
AddType text/x-component htc
Alias /i/ /mdx/app/oracle/product/10.2.0/http/Apache/Apache/images/
<Location /pls/htmldb>
Order deny,allow
PlsqlDocumentPath docs
AllowOverride None
PlsqlDocumentProcedure wwv_flow_file_manager.process_download
PlsqlDatabaseConnectString xxxxxx.xxxxx.ac.uk:1521:orcl ServiceNameFormat
PlsqlNLSLanguage "ENGLISH_UNITED KINGDOM.AL32UTF8"
PlsqlAuthenticationMode Basic
SetHandler pls_handler
PlsqlDocumentTablename wwv_flow_file_objects$
PlsqlDatabaseUsername HTMLDB_PUBLIC_USER
PlsqlDefaultPage htmldb
PlsqlDatabasePassword @BWIuxxxxxxxxxxxxxxxxxxxxxxid4Y4t8b9g==
Allow from all
</Location>
and I started the http again, and it works fine.
Problem solved. I will try to fine tune it so I'll get the basic LANG setting back in linux but without the .UTF-8 postfix.
thanks for your help,
Erik

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

Upgrading apex from 1.6.1.00.03 to 3.1.0.00.32

hi all
i have two servers
right now we've upgrade the apex in one of the server to 3.1.0.00.32 from 1.6.1.00.03 and the other is
still in the old version 1.6.1.00.03
i want to ask if there is any important changes between the versions
and if can be any important thing that i should know or need to check between the versions? like run specific type of pages etc.
do i need to check specific thing on the new version ?
like inserting to d.b or running reports etc.
is there a problem to develope on the new version and after that doing import to the old version and contrary ?
thanks in advance

Hello Naama,
>> right now we've upgrade the apex in one of the server to 3.1.0.00.32 from 1.6.1.00.03 and the other is still in the old version 1.6.1.00.03 . . . is there a problem to develope on the new version and after that doing import to the old version and contrary ?
First, congratulation and welcome to the new world of APEX. I’m not just saying that, because there are some significant changes between v1.6 and 3.1 (as a matter of fact, there are significant changes between v1.6 and all the following versions, mainly because version 2.0 introduced the AJAX framework, which forced some changes in the APEX configuration).
The situation you are describing – one 1.6 server and another one in 3.1 – can be problematic because you can’t installed (import) applications from v3.1 into a 1.6 server. That means that if your development instance will be the 3.1, you won’t be able to deploy the applications to the 1.6 server. If you’ll continue to use the 1.6 for development, you won’t gain much from upgrading to 3.1 .
>> i want to ask if there is any important changes between the versions
and if can be any important thing that i should know or need to check between the versions?
As I said, you need to be aware of the configuration changes between the versions. It’s important to check your PL/SQL Web toolkit version (http://download.oracle.com/docs/cd/E10513_01/doc/install.310/e10496/pre_require.htm#BABGBJJD ), and upgrade it if necessary. You can find a proper version in the APEX 3.1 distribution files. Moreover, you’ll need to change your DAD file. You’ll need to add the two “AddType” entries, and probably set the charset portion of the PlsqlNLSLanguage entry to AL32UTF8. This is a mandatory setting, regardless of your database charcter set - http://download.oracle.com/docs/cd/E10513_01/doc/install.310/e10496/post_inst.htm#CHDHCBGI .
Functionality wise, if your configuration is correct, you don’t need to worry. Everything should be running as usual, without any problems (there were some minor changes in the way newer versions handle certain things, especially because some security enhancements, but you might not encounter them, so let’s cross that bridge if we’ll come to it).
Good Luck,
Arie.

PlsqlNLSLanguage WE8ISO8859P1 vs AL32UTF8

Similar Messages

Maybe you are looking for