7

I have Oracle SQL Developer (3.1.07) and I'm trying to work with a database that uses WE8ISO8859P1 encoding:

SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

I have problems with saving packages that contains unicode symbols. When I open previously saved package all unicode symbols are turned to '¿'.

What settings do I have to change to make SQL Developer keep those symbols? I've tried to set environment encoding to 'ISO-8859-15' and some other encodings, but it won't help.

Ollie
  • 17,058
  • 7
  • 48
  • 59
ULazdins
  • 1,975
  • 4
  • 25
  • 31

4 Answers4

1

If your database encodes text to a non-unicode single-byte encoding (e.g. ISO-8859), any symbol not present on the character table will be seen as invalid and replaced by a placeholder. You can't go back from that, the information is lost.

That can be usually worked around when storing data, but as for source code, you cannot control how Oracle would encode your strings.

If your database is configured to use such encoding scheme you're probably not supposed to write code that violates its rules.

mycelo
  • 409
  • 5
  • 4
0

At least to open PKG in sql developer, you can do a quick try and see if it works:-

Change SQL Developer 'encoding' to 'unicode-utf-8' which is default to later versions now.

You would ,eventually, need to go for database charset migration to 'AL32UTF8' to avoid other issues (like data) due to this char set.

pahariayogi
  • 1,073
  • 1
  • 7
  • 18
0

If you look at USER_SOURCE you'll see that the source code, as stored/interpreted by the database, will be in a VARCHAR2 column so use the database character set. As such, your source code will need to be in WE8ISO8859P1.

In theory, if the client and database are using the same character set, then the database won't try to do any character set translation and you may be able to sneak in a sequence of bytes that the database thinks are WE8ISO8859P1 but will make sense in unicode. However, at some point, someone will use the wrong client and it will break.

You don't need unicode for identifiers etc in the code, so I assume it is in string literals. You are better off storing these in a table (NVARCHAR2 column) and selecting them into the code rather than hard-coding them. If that isn't possible, you could use UNISTR and hard-code the relevant hex values.

Gary Myers
  • 34,963
  • 3
  • 49
  • 74
0

Maybe you could need this character set migration

http://docs.oracle.com/cd/B10501_01/server.920/a96529/ch10.htm#1656

on the Oracle's documentation

Deblaton Jean-Philippe
  • 11,188
  • 3
  • 49
  • 66