Re: import fails due to different character set

  • From: Gints Plivna <gints.plivna@xxxxxxxxx>
  • To: john.kanagaraj@xxxxxxx
  • Date: Thu, 9 Feb 2006 10:59:50 +0200

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.

2006/2/9, John Kanagaraj <john.kanagaraj@xxxxxxx>:
> Raghu,
>
> Have a look at the error message - it is "value too large for column". UTF8
> is a mult-byte characterset while the older WE8..P1 is a single byte
> characterset. In the LEGAL_LAST_NAME column, you have one or more rows which
> has at least one or more special characters which expands from the WE8
> single byte entry to occupy a UTF8 double (or multi-byte) entry. You will
> have to expand the LEGAL_LAST_NAME column to accomodate this expansion.
>
> And while you are it, you might as well expand those other columns which may
> possibly hold special characters. This is especially true for Name
> columns...
>
> Hth,
> John Kanagaraj <><
> DB Soft Inc
> Phone: 408-970-7002 (W)
>
--
//www.freelists.org/webpage/oracle-l


Other related posts: