Well export and import actually do do the character set conversions -- whenever possible the CLIENT, not the database does them.

but, that aside -- is the column JR0038 actually large enough -- you know, something that takes 30 bytes in one database might take 60 bytes in the other. Have you looked at the actual size of that column to see if it might really need to be increased???


In fact, in looking at note <Note:99120.1>, i would definitely say this is the cause of BOTH errors -- that in ja16sjis this string takes X bytes and in UTF8 it is taking X+N bytes and X+N exceeds the MAXIMUM string length.

<quote>
Explanation 1
-------------
In the UTF8 characterset a lot of characters (like the ones from the extended
ASCII set) need more than 1 byte to be stored. For example in WE8ISO8859P1 and
similar single byte charactersets the character "ê" takes 1 byte of storage but
it takes 2 bytes to store the same character in UTF8.

A definition of a VARCHAR2 column gives the size in bytes, not in characters.
That means a varchar2(2) in a WE8ISO8859P1 database can store the string "êe"
without problems. A similar varchar2(2) column in a UTF8 database would not be
able to store it since it would take 3 bytes (2 for ê and 1 for the simple e)
to store that string.

When export starts it simply takes a look at the definition of a table and
expects data of that size. However, if the characterset in the NLS_LANG variable
is set to UTF8, the strings selected from the database will be converted into
UTF8. If we follow the above example again the following would happen: The
WE8ISO8859P1 database has got a varchar2(2) column that happily stores the
string "êe" in 2 bytes. Export starts and expects the strings to be of a
maximum size of 2 bytes. When the rows are returned they are converted into
UTF8, meaning that for the row with "êe" 3 bytes are presented to exp instead
of the expected 2 bytes. When this happens the EXP-15 and EXP-1 errors are
returned.


Solution 1
----------
Set the characterset in NLS_LANG to a single byte characterset that is correct
for your platform. There is no reason why this shouldn't be possible.
</quote>



so, you followed the work around but upon IMPORT you see the other side effect - -the string in the dmp file is still TOO LARGE to fit in the column (it was too large to have exp convert it, it is too large for imp to import it)

You must widen this column to hold this data.