Re: import fails due to different character set
- From: Gints Plivna <gints.plivna@xxxxxxxxx>
- To: john.kanagaraj@xxxxxxx
- Date: Thu, 9 Feb 2006 11:44:17 +0200
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/ch1121.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@xxxxxxxxx>:
> 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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
