Re: Oracle 7 -> Oracle 8 + 8th bit problem and NLS_LANG

Hi,

I'm just making a guess out here. I can only think of the following solution. * I guess you do have proper Big5 character data in an us7ascii charset database.

   The way they might have gone in there unaltered is when you had specified    nls_lang as american_america.us7ascii. This way if client and server charset is the same,    oracle did not do any conversion while putting that data in. * The question is, what charset is that data in (or originally was). I'm assuming that

   the original charset was zht16big5 (If not then you would need to find that out)

• If the above two statements are true, then frankly this (which you might have already tried) might work. set nls_lang on oracle7 server to american_america.us7ascii ... spool out the data .. or do a direct export (This way .. again, I would not expect oracle to do attempt a charset conversion). set nls_lang on oracle8 machine to american_america.zht16big5 ... load the data using sqlldr .... or import the data.
• If this does not work then probably either the data in oracle7 is in some other charset .... ..or you are not using proper utilities to figure out what the data looks like finally (though this seems unlikely ..)

Sorry ... I couldn't be of more help.

Anurag

"Georges KO" <gko_at_gko.net> wrote in message news:ybybs7n1bi6.fsf_at_gko.net...
> Georges KO <gko_at_gko.net> writes:
>
> > Actually, what I need is really simple: transfer raw data from
> > Oracle 7 to Oracle 8 only without stripping the 8th bit, in an Oracle
> > job...
>
> I would need something like this (XX and YY are Chinese characters):
>
> SQL> select rawtohex('XXYY') from custom_at_oracle7db
>
> RAWTOHEX
> --------
> A5DFB0EA
>
> SQL> select what_i_need(rawtohex('XXYY') from custom_at_oracle7db
>
> and what_i_need() would translate 'A5DFB0EA' back to 'XXYY',
> to be inserted into the column...
Received on Wed Aug 28 2002 - 07:21:35 CDT