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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bobak, Mark
Sent: Thursday, 10 May 2007 1:22 AM
To: don_at_seiler.us; 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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] 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_at_seiler.us> 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
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l