RE: Change database character set
- From: Scott Canaan <srcdco@xxxxxxx>
- To: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>, Niall Litchfield <niall.litchfield@xxxxxxxxx>
- Date: Fri, 24 Oct 2014 12:04:14 +0000
Actually, I’ve been considering doing something similar to this. The 9 rows in
that table (out of about 20) that are affected were added in August and the
person that added them still has the original documents, so they could be
reloaded after the conversion. I believe that what is in the HUGECLOB in that
table is just a word document that was cut and pasted into the field.
The only row that really concerns me is the one in SYS.REG$.
Scott Canaan ’88 (srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>)
(585) 475-7886 – work (585) 339-8659 – cell
“Life is like a sewer, what you get out of it depends on what you put into it.”
– Tom Lehrer
From: Chris Taylor [mailto:christopherdtaylor1994@xxxxxxxxx]
Sent: Friday, October 24, 2014 8:01 AM
To: Niall Litchfield
Cc: Scott Canaan; oracle.unknowns@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Change database character set
Based on Niall's analysis, another option could be to export the SCRIPT_GROUP
table, truncate it, do the conversion and reload it (depending on the size).
Chris
On Fri, Oct 24, 2014 at 5:02 AM, Niall Litchfield
<niall.litchfield@xxxxxxxxx<mailto:niall.litchfield@xxxxxxxxx>> wrote:
Scott
I'm pretty sure you'll find the session_key row is transient and due to an
emagent (either grid/cloud control or dbconsole) - there's a note on csscan
dictionary errors that will tell you. That leaves you with 9 documents (they
look like word docs/emails). Can you grab those from the app and reenter the
data post conversion?
Other related posts:
