Hi,

We have problems in importing an Oracle 8 database into Oracle 9 server.
Polish national characters do not transfer correctly.

The import comes up with the following message:
------------------------------------------
import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
export server uses WE8ISO8859P1 NCHAR character set (possible ncharset
conversion)
------------------------------------------
(The original message in Polish is:
import wykonany dla zestawu znakow WE8ISO8859P1 i zestawu znakow AL16UTF16
NCHAR
serwer eksportu uzywa zestawu znakow WE8ISO8859P1 NCHAR (mozliwa konwersja
zesta
wu znakow)

The target database uses WE8ISO8859P1 character set and AL16UTF16 NCHAR
character set, and the nls_lang was set to POLISH_POLAND.WE8ISO8859P1, still
the Polish characters are not transferred correctly, except "ó", whose ASCII
code is below 256.

Did anyone meet such a problem?

Regards,
D.W.

On Jun 21, 12:03 pm, "majster" <majs...@majster.com> wrote:
> Hi,
>
> We have problems in importing an Oracle 8 database into Oracle 9 server.
> Polish national characters do not transfer correctly.
>
> The import comes up with the following message:
> ------------------------------------------
> import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
> export server uses WE8ISO8859P1 NCHAR character set (possible ncharset
> conversion)
> ------------------------------------------
> (The original message in Polish is:
> import wykonany dla zestawu znakow WE8ISO8859P1 i zestawu znakow AL16UTF16
> NCHAR
> serwer eksportu uzywa zestawu znakow WE8ISO8859P1 NCHAR (mozliwa konwersja
> zesta
> wu znakow)
>
> The target database uses WE8ISO8859P1 character set and AL16UTF16 NCHAR
> character set, and the nls_lang was set to POLISH_POLAND.WE8ISO8859P1, still
> the Polish characters are not transferred correctly, except "ó", whose ASCII
> code is below 256.
>
> Did anyone meet such a problem?
>
> Regards,
> D.W.

The problem is
> import done in WE8ISO8859P1 character set and *AL16UTF16* **NCHAR** character set
> export server uses *WE8ISO8859P1* **NCHAR** character set (possible ncharset
> conversion)

Your Oracle 9i database has an incorrect NCHAR characterset (NON-UTF)

--
Sybrand Bakker
Senior Oracle DBA

Thanks a lot for your answer.

> The problem is
> > import done in WE8ISO8859P1 character set and *AL16UTF16* **NCHAR**
character set
> > export server uses *WE8ISO8859P1* **NCHAR** character set (possible
ncharset
> > conversion)
>
> Your Oracle 9i database has an incorrect NCHAR characterset (NON-UTF)

What solution to the problem would you recommend? We are new to Oracle (we
used MSSQL before), and the source database is legacy and "as-is". We would
just like to import it correctly.

DW.

On Jun 21, 2:29 pm, "majster" <majs...@majster.com> wrote:
> Thanks a lot for your answer.
>
>
>
> > The problem is
> > > import done in WE8ISO8859P1 character set and *AL16UTF16* **NCHAR**
> character set
> > > export server uses *WE8ISO8859P1* **NCHAR** character set (possible
> ncharset
> > > conversion)
>
> > Your Oracle 9i database has an incorrect NCHAR characterset (NON-UTF)
>
> What solution to the problem would you recommend? We are new to Oracle (we
> used MSSQL before), and the source database is legacy and "as-is". We would
> just like to import it correctly.
>
> DW.

It looks like the procedure is described here
http://download-uk.oracle.com/docs/c...10.htm#1010387

The description seems to be a bit shaky.
What I would do is set up export tables with the PK of the original
table and the NCHAR columns of the original tables.
Only then you would be able to 'drop' those columns.
This link also describes the procedure to change the NCHAR set of your
9i database, which needs to happen anyway, as your current
characterset is not supported.

Hth

--
Sybrand Bakker
Senior Oracle DBA

> It looks like the procedure is described here
>
http://download-uk.oracle.com/docs/c...10.htm#1010387
>
> The description seems to be a bit shaky.
> What I would do is set up export tables with the PK of the original
> table and the NCHAR columns of the original tables.
> Only then you would be able to 'drop' those columns.
> This link also describes the procedure to change the NCHAR set of your
> 9i database, which needs to happen anyway, as your current
> characterset is not supported.

I am not sure if our situation was put in a clear way, so I will try again.

Our client provided an *.dmp file exported from Oracle 8 server and we would
like to import it with an Oracle 9i server by the "imp" utility. We have no
way to import the file in Oracle 8 server because we have no license for it.

The *.dmp file looks good. When it is viewed as a simple ANSI (windows-1250)
text (e.g. in windows notepad), the Polish characters are there.

DW

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

majster wrote:

> Our client provided an *.dmp file exported from Oracle 8 server and we would
> like to import it with an Oracle 9i server by the "imp" utility. We have no
> way to import the file in Oracle 8 server because we have no license for it.

Ask for the log of the export - see if there are warnings about
possible charset conversion.

Another question - are the local characters stored in
(var)char, or Nvarchar data types?

- --
Regards,
Frank van Bortel

Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFGesvYLw8L4IAs830RArWjAJ9zh/0I/5Ytsn9QF7iJGkwRTnKpBACeLTux
UM+U4J3ZsH8mxOFW8zDKkN4=
=33J4
-----END PGP SIGNATURE-----

Thanks for Your reply.

> Ask for the log of the export - see if there are warnings about
> possible charset conversion.
>
> Another question - are the local characters stored in
> (var)char, or Nvarchar data types?

The exported file looks OK. If you just view it as ANSI text (i.e.
windows-1250 codepage), all the texts look OK, the national characters are
there ant they are the correct ones. That would suggest that the varchar
type was used (provided varchar/nvarchar have similar meaning as in MSSQL,
namely non-unicode/unicode).

DW

On Jun 22, 9:49 am, "majster" <majs...@majster.com> wrote:
> Thanks for Your reply.
>
> > Ask for the log of the export - see if there are warnings about
> > possible charset conversion.
>
> > Another question - are the local characters stored in
> > (var)char, or Nvarchar data types?
>
> The exported file looks OK. If you just view it as ANSI text (i.e.
> windows-1250 codepage), all the texts look OK, the national characters are
> there ant they are the correct ones. That would suggest that the varchar
>

WE8ISO8859P1 corresponds to Windows-1252 whereas I assume Windows-1250
would correspond to EEISO8859P2. Storing polish characters (not
supported in 8859P_1_) in a WE8ISO8859P1 Database-Column does not make
sense to me.


> type was used (provided varchar/nvarchar have similar meaning as in MSSQL,
> namely non-unicode/unicode).
>
> DW

You might want to check out the docs:
* DATATYPES: http://download-uk.oracle.com/docs/c...elements2a.htm
* IMP/EXP: http://download-uk.oracle.com/docs/c...6652/part1.htm

If your data is in NVARCHAR/NCHAR columns you really need to
understand waht that implies. (*I* sure don't at the moment but I do
not use these datatypes, we use UTF-8 VARCHAR2)

br,
Martin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

majster wrote:
> Thanks for Your reply.
>
>> Ask for the log of the export - see if there are warnings about
>> possible charset conversion.
>>
>> Another question - are the local characters stored in
>> (var)char, or Nvarchar data types?
>
> The exported file looks OK. If you just view it as ANSI text (i.e.
> windows-1250 codepage), all the texts look OK, the national characters are

LOG - not the export - you should not be poking around in the export
(.dmp) file.

You still did not reply to the varchar/nvarchar question.
If your data is sored in nvarchar, follow Sybrands suggestions.

- --
Regards,
Frank van Bortel

Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFGfBS0Lw8L4IAs830RAosXAJwOQ/4Sx1LzC65q5Y77Fk6kFocj6QCgnMep
SuNMT/AzR0TLZP3kCgdxhNg=
=n0hZ
-----END PGP SIGNATURE-----