Re: Character set for exp/imp

From: astalavista <nobody_at_nowhere.com>
Date: Thu, 6 Nov 2008 09:50:31 +0100
Message-ID: <4912afd2$0$19725$426a74cc@news.free.fr>

"Laurenz Albe" <invite_at_spam.to.invalid> a écrit dans le message de news: 1225957994.170209_at_proxy.dienste.wien.at...
> Michel Cadot <micadot{at}altern{dot}org> wrote:
>> | I have to migrate a database WE8ISO8859P1 (8i) to
>> | to another database AL32UTF8 (9i)
>> | I did an export with NLS_LANG=.WE8ISO8859P1
>> | what is the right NLS_LANG to do the import ?
>> | when I tried the import with WE8ISO8859P1 or AL32UTF8
>> | I got a warnings about conversion.
>> | what is the right NLS_LANG to do the import ?
>> | or it doesn't matter ?
>> |
>> | Thanks in advance
>> |
>>
>> WE8ISO8859P1
>>
>> Of course you have conversion because you convert from a
>> character set to another very different one.
>> But it is just code point changes and not character changes.
>
> You might run into a problem if you have characters in your database that
> require more than one byte.
>
> If for example a field was defined as CHAR(3) in your old database,
> the table created by the import will also be CHAR(3), and since your
> old database probably had NLS_LENGTH_SEMANTICS set to BYTE, the new
> field will actually be CHAR(3 BYTE).
>
> If you had a value 'été' in that column, it will generate an error during
> import because that string needs 5 bytes in UTF-8, but the column can
> contain only 3 bytes.
>
> You will have to change the table manually so that the field is
> CHAR(3 CHAR).
>
> Yours,
> Laurenz Albe

OK thanks Michel and Laurenz
I precreated the tables with CHAR semantics so I think the problem is managed Received on Thu Nov 06 2008 - 02:50:31 CST

Original text of this message