RE: [SPAM] Re: Interpreting csscan results
- From: "Clarke, Andrew" <andrew.clarke@xxxxxxxxxxxxx>
- To: <mcdonald.connor@xxxxxxxxx>, "oracle_l" <oracle-l@xxxxxxxxxxxxx>, <don@xxxxxxxxx>
- Date: Thu, 10 May 2007 15:09:52 +0100
A little unfair to blame developers. It is more than likely to be the
users. We had a similar problem with loading data into a warehouse from
applications which used MS products for data entry (or at least
cut'n'paste from Word docs, etc).
The confusion stems from the characters showing up as problematic in the
target character set. They are also a problem in the existing character
set. Select them in a USASCII7 SQL*Plus session and they'll probably
present as an upside-down question mark.
> I'm researching the idea of migrating to WE8ISO8859P1.
If these are smart quotes or other MS characters you might wish to
consider migrating to WE8MSWIN1252
Cheers, APC
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Connor McDonald
Sent: 10 May 2007 14:00
To: 'oracle_l'
Subject: RE: [SPAM] Re: Interpreting csscan results
A very common cause is developers cut-pasting comments/documentation
from
products such as MS-Word directly into their source code - in our case,
"smart quotes" was a drama when we converted away from US7ASCII
hth
Connor
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Bobak, Mark
Sent: Thursday, 10 May 2007 1:22 AM
To: don@xxxxxxxxx; oracle_l
Subject: RE: [SPAM] Re: Interpreting csscan results
Off the top of my head, perhaps there's an 'invisible' control character
in
there?
Try this:
Select source,dump(source) from sys.source$ where rowid =
'AAAABHAABAAAHqVABL';
Do you see anything odd or suspicious?
--
Mark J. Bobak
Senior Oracle Architect
ProQuest/CSA
"There are 10 types of people in the world: Those who understand
binary,
and those who don't."
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Don Seiler
Sent: Wednesday, May 09, 2007 12:12 PM
To: oracle_l
Subject: [SPAM] Re: Interpreting csscan results
Importance: Low
I looked deeper into the specific exceptions. All of the data
dictionary
exceptions are just histograms on the application data fields with the
WestEuro characters, except for this oddball:
User : SYS
Table : SOURCE$
Column: SOURCE
Type : VARCHAR2(4000)
Number of Exceptions : 1
Max Post Conversion Data Size: 4000
ROWID Exception Type Size Cell Data(first 30 bytes)
------------------ ------------------ -----
------------------------------
AAAABHAABAAAHqVABL lossy conversion end;
------------------ ------------------ -----
------------------------------
Not sure why "end;" is a problem.
Don.
On 5/9/07, Don Seiler <don@xxxxxxxxx> wrote:
> Morning all. Our production database (10.2.0.2 on RHEL3) is USASCII7,
> and we've recently had issues with western euro characters being used.
> I'm researching the idea of migrating to WE8ISO8859P1.
>
> So last night I ran csscan with those from/to parameters, and I'm more
> than a little confused. My reading led me to believe that since
> WE8ISO8859P1 is a complete superset of USASCII7, there should be no
> issues. Perhaps I'm just interpreting the results wrong.
>
> The scan summary says:
> Some character type data in the data dictionary are not convertible to
> the new character set Some character type application data are not
> convertible to the new character set
>
> Here is the summary for each data dictionary and app data:
>
> [Data Dictionary Conversion Summary]
>
> Datatype Changeless Convertible
> Truncation Lossy
> --------------------- ---------------- ----------------
> ---------------- ----------------
> VARCHAR2 17,344,573 0
> 0 30
> CHAR 1,216 0
> 0 0
> LONG 916,150 0
> 0 0
> CLOB 1,505,729 0
> 0 0
> VARRAY 17,408 0
> 0 0
> --------------------- ---------------- ----------------
> ---------------- ----------------
> Total 19,785,076 0
> 0 30
> Total in percentage 100.000% 0.000%
> 0.000% 0.000%
>
> The data dictionary can not be safely migrated using the CSALTER
> script
>
> [Application Data Conversion Summary]
>
> Datatype Changeless Convertible
> Truncation Lossy
> --------------------- ---------------- ----------------
> ---------------- ----------------
> VARCHAR2 49,180,912,298 0
> 0 11,819
> CHAR 10,295,777,604 0
> 0 736
> LONG 4,957 0
> 0 0
> CLOB 1 0
> 0 0
> VARRAY 0 0
> 0 0
> --------------------- ---------------- ----------------
> ---------------- ----------------
> Total 59,476,694,860 0
> 0 12,555
> Total in percentage 100.000% 0.000%
> 0.000% 0.000%
>
> The scan.err file lists those names with mangled WE characters with a
> "lossy conversion" exception. I'm wondering if this (in particular
> the data dictionary warning) means my database will be horribly
> corrupted if I try CSALTER, or if it just means I will have to correct
> those particular fields afterward.
>
> --
> Don Seiler
> oracle blog: http://ora.seiler.us
> ultimate: http://www.mufc.us
>
--
Don Seiler
oracle blog: http://ora.seiler.us
ultimate: http://www.mufc.us
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
