RE: import fails due to different character set

Thank you Gints, yeah metalink also suggested similar solution, I am just trying its working. Thanks again to all.

Solution:-

-Set the NLS_LENGTH_SEMANTICS='CHAR' on importing database
-Precreate the table with CHAR semantics
-Retry the import

-----Original Message-----
From: Gints Plivna [mailto:gints.plivna_at_gmail.com] Sent: Thursday, February 09, 2006 4:44 AM To: john.kanagaraj_at_hds.com
Cc: Kota, Raghu; oracle-l_at_freelists.org
Subject: Re: import fails due to different character set

Some more thoughts about this one.

Just remembered of a parameter nls_length_semantics. Default value for it is BYTE. But one can either alter system or session to CHAR and then all newly created tables (and it seems executed programm units as well) uses character length semantics.
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch11 21.htm#REFRN10124
So it seems you can set this parameter on DB level and import should run fine...
Don't know if it has any other possible downsides though.

Gints

2006/2/9, Gints Plivna <gints.plivna_at_gmail.com>:
> Yea I had the same problem several months ago and the only solution
> was to precreate tables using VARCHAR2(XXX CHAR). Or probably you can
> modify necessary tables created by import. Unfortunately it was only
> least half of pain. The biggest pain is that you have to modify your
> code that is based on these tables, but haven't been written in a
> correct way, because variables has the same problem as table columns.
> So unless variables in your code is not based on tables and table
> columns for example
> var table.column%TYPE;
> but simply written like
> var varchar2(xxx);
> you have a big potential pain...
>
> One more reason to use %TYPE and %ROWTYPE.
>
> Gints
>
> P.S. A few weeks ago there was similar thread here about multi byte
charsets.

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