RE: [SPAM] Re: Interpreting csscan results
- From: "Connor McDonald" <mcdonald.connor@xxxxxxxxx>
- To: "'oracle_l'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 10 May 2007 20:59:30 +0800
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
Other related posts:
