1

I'm trying to figure out the reason why Oracle SQL Developer shows question marks/rubbish on non-latin symbols. Currently I have 2 DBs on separate severs/instances, one of which works fine, and the other one breaks encoding as written above. Both were checked with same SQL Developer with same environment WITHOUT NLS_LANG set.

Here are NLS* tables for each case:

Normal)

select * from nls_database_parameters; NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET CL8MSWIN1251 NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_RDBMS_VERSION 10.2.0.3.0

select * from nls_instance_parameters; NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT NLS_DUAL_CURRENCY
NLS_COMP
NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE

Strange)

select * from nls_database_parameters; NLS_RDBMS_VERSION 12.1.0.2.0 NLS_NCHAR_CONV_EXCP FALSE NLS_LENGTH_SEMANTICS BYTE NLS_COMP BINARY NLS_DUAL_CURRENCY $ NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_SORT BINARY NLS_DATE_LANGUAGE AMERICAN NLS_DATE_FORMAT DD-MON-RR NLS_CALENDAR GREGORIAN NLS_NUMERIC_CHARACTERS ., NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_CHARACTERSET CL8MSWIN1251 NLS_ISO_CURRENCY AMERICA NLS_CURRENCY $ NLS_TERRITORY AMERICA NLS_LANGUAGE AMERICAN
select * from nls_instance_parameters; NLS_LANGUAGE RUSSIAN NLS_TERRITORY RUSSIA NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT NLS_DUAL_CURRENCY
NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE

Session params)

select * from nls_session_parameters; NLS_LANGUAGE ENGLISH NLS_TERRITORY UNITED KINGDOM NLS_CURRENCY ? NLS_ISO_CURRENCY UNITED KINGDOM NLS_NUMERIC_CHARACTERS ., NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE ENGLISH NLS_SORT BINARY NLS_TIME_FORMAT HH24.MI.SSXFF NLS_TIMESTAMP_FORMAT DD-MON-RR HH24.MI.SSXFF NLS_TIME_TZ_FORMAT HH24.MI.SSXFF TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH24.MI.SSXFF TZR NLS_DUAL_CURRENCY € NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE

Changing strange's instance NLS-params didn't do the trick. Data integrity is verified - a webapp that connects to this DB works fine if NLS_LANG is explicitly set to RUSSIAN_RUSSIA.CL8MSWIN1251. I just can't figure out why FIRST database works fine as is and the SECOND has to be explicitly configured client-side, even if I change instance settings. What am I missing?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.