Re: replication: problem with character "degree" celcius

On Jun 12, 9:18 am, Charles Hooper <hooperc2..._at_yahoo.com> wrote:
> On Jun 12, 7:46 am, sybrandb <sybra..._at_gmail.com> wrote:
>
> > On Jun 12, 1:39 pm, Charles Hooper <hooperc2..._at_yahoo.com> wrote:
> > > The problem appears to be that Oracle permitted your application to
> > > store an 8 bit ASCII value in a 7 bit ASCII database: 176 > 127.
>
> > > Charles Hooper
> > > IT Manager/Oracle DBA
> > > K&M Machine-Fabricating, Inc.
>
> > This will happen if client is 7-bit ASCII AND server is 7-bit ASCII.
> > In that case there will be no conversion and everything even > 128
> > will pass.
>
> > --
> > Sybrand Bakker
> > Senior Oracle DBA
>
> Thanks for the explanation.
>
> If the OP were to convert the source database from 7 bit ASCII to 8
> bit ASCII (WE8ISO8859P1), would that resolve the problem without
> losing the existing high bit of the ASCII characters for ASCII
> characters >= 128, so that ASCII 176 does not become ASCII (176 -
> 128)?
>

Depends how he converts it. exp/imp will definitely mess it up unless one reallys understand the NLS settings (there are metalink docs as well as some discussions here about that). For the conversion in place, run the csscan utility that checks to see if there are problems. http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14225/ch12scanner.htm My guess-without-checking would be the superset wouldn't be a problem, but it depends on the data - if there's one character, there might be others...

jg

--
@home.com is bogus.
Überwhippet: http://www.signonsandiego.com/uniontrib/20070612/news_1n12genome.html