I think WE8ISO8859P1 does not have the euro glyph
you should be using WE8ISO8859P15 or UTF-8
(preferably, in particular if that is what you db is using anyway)
Is there an NLS_LANG setting in the SQL Developer client?
Actually did you know that Euro is not a character in WE8ISO8859P1.
So your problem is not SQL Developer, but the character set of the database.
You should get the Euro displayed from this:
select UNISTR('\20AC'), dump(UNISTR('\20AC'),1016) from dual;
Sorry to bother you again
Just for quick reference, that prior, unresolved discussion is: Re: Problems with € simbol
I do not understand is why it works in SQL Plus and Toad and not in the SQLDeveloper
From the prior discussion, keep in mind that JDBC is not SQL*Net...
Depending on what that is [i.e, the database's NLS_CHARACTERSET], possibly JDBC must do some characterset conversion that SQL*Plus over SQL*Net does not, even if it is only for a literal string in a SELECT ... FROM DUAL statement.
As other posters suggest, the solution is to use a database characterset that supports the euro symbol.
And if you wish to gain a deeper understanding of what is happening in terms of character translation between the DB and the different types of clients (Java vs SQL*PLus, say), you may wish to search or post in the Database > Globalization Support forum. One of the top posters there, Sergiusz Wolicki from Oracle Poland, made these comments in a 5+ year old AskTom (https://asktom.oracle.com/pls/apex/f?p=100:11:::NO:RP:P11_QUESTION_ID:1224836384599) post:
many WE8ISO8859P1 databases actually contain Windows-specific character codes, i.e. codes defined in WE8MSWIN1252 but not defined in WE8ISO8859P1 (ok, actually defined but as control codes). They include "smart" quotes, Euro currency symbol, bullet symbol, TM symbol, en-dash, em-dash, French ligature oe, etc.... In 11g, WE8ISO8859P1 is not on the list of recommended character sets available in OUI.
So something like that is likely the issue. Once such codes get into the database, they come out OK if no translation is performed. Any attempt to translate such unsupported characters from the database characterset will produce garbled output.
You have now proven that SQL Developer can handle Euro, so I think the issue is the database characterset.
Thank you very much for the answers.
Unfortunately I do not have DBA access to the database, but when I can try to change the character set.
Again, thank you all.