I tested your example in two different databases with different NLS_CHARACTERSET configurations.
Configurations (retrieved on request -
select * from v$nls_parameters where parameter in ('NLS_NCHAR_CHARACTERSET','NLS_CHARACTERSET','NLS_LANGUAGE')
):
At first:
+----+------------------------+----------+ | id | PARAMETER | VALUE | +----+------------------------+----------+ | 1 | NLS_LANGUAGE | AMERICAN | | 2 | NLS_CHARACTERSET | AL32UTF8 | | 3 | NLS_NCHAR_CHARACTERSET | AL16UTF16| +----+------------------------+----------+
Secondly:
+----+------------------------+-------------+ | id | PARAMETER | VALUE | +----+------------------------+-------------+ | 1 | NLS_LANGUAGE | RUSSIAN | | 2 | NLS_CHARACTERSET | CL8MSWIN1251| | 3 | NLS_NCHAR_CHARACTERSET | AL16UTF16 | +----+------------------------+-------------+
And the result is the following: on DB with charset variable AL32UTF8 displayed correctly, on charset CL8MSWIN1251 with questions "???".
I do not modify the charsests in the databases to confirm my suggestion. Therefore, I suggest you change NLS_CHARACTERSET to AL32UTF8 , this should help.
My test package:
create or replace package question27577711 is x constant nvarchar2(3) default 'մեկ'; function get_constant_x return nvarchar2; end question27577711; create or replace package body question27577711 is function get_constant_x return nvarchar2 is begin return x; end get_constant_x; end question27577711; select question27577711.get_constant_x from dual
source share