Colega, só um esclarecimento antes de responder : quando vc diz
"...trigger, ... , a mesma foi rodada num client..." , isso NÂO É
preciso, a trigger NUNCA é rodada NUM CLIENTE, e sim SEMPRE NO
SERVIDOR, e SEMPRE é disparada pelo próprio banco em resposta a uma
ação do usuário, nunca é disparada pelo próprio usuário, ok ??
Agora sim respondendo : pensando em triggers de DML (parece ser o seu
caso aqui), como vc sabe, quando a trigger é disparada, ela roda
EXATAMENTE NA MESMA sessão do cliente que enviou o SQL ao banco -
entre outros fatores, isso TEM que ser assim porque, afinal de contas,
uma sessão DIFERENTE não ia conseguir ver os valores não-comitados , e
a trigger (pensando em FOR EACH ROW) ** precisa desses valores ** para
os acessar via :new/:old, confere ??? Já que é na mesma sessão, ÓBVIO,
a trigger usará exatamente os MESMOS settings NLs (e tudo o mais!!)
que existe na sessão. Exemplo :
[EMAIL PROTECTED]:SQL>select * from NLS_SESSION_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT dd/mm/yyyy hh24:mi:ss
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
17 rows selected.
==> ok, no banco tenho AMERICAn como language, vamos ver numa dada
sessão :
[EMAIL PROTECTED]:SQL>select * from NLS_SESSION_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE BRAZILIAN PORTUGUESE
NLS_TERRITORY BRAZIL
NLS_CURRENCY Cr$
NLS_ISO_CURRENCY BRAZIL
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT dd/mm/yyyy hh24:mi:ss
NLS_DATE_LANGUAGE BRAZILIAN PORTUGUESE
NLS_SORT WEST_EUROPEAN
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY Cr$
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 linhas selecionadas.
==> tenho brazilian... OK, vamos ver o sid/serial desa sessão :
[EMAIL PROTECTED]:SQL>select * from v$session where username='SCOTT';
SADDR SID SERIAL# AUDSID PADDR USER# USERNAME
COMMAND OWNERID TADDR LOCKWAIT STATUS SERVER
SCHEMA# SCHEMANAME
-------- ---- ------- -------- -------- ----- ----------------
------------------ ------------------ -------- -------- --------
--------- ------------------ -----------
702441A8 9 9 178 702190B4 64 SCOTT
0 2147483644 70BACE6C INACTIVE DEDICATED
64 SCOTT
==> agora vamos ter uma trigger que exibe (via output, que PORTANTO já
deverá estar ligado antes) os valores :
[EMAIL PROTECTED]:SQL>l
1 create or replace trigger TRG_DEPT after insert on DEPT for each row
2 DECLARE
3 v_lang varchar2(2000);
4 v_sid number;
5 v_serial# number;
6 BEGIN
7 select value into v_lang from NLS_SESSION_PARAMETERS where
parameter='NLS_LANGUAGE';
8 dbms_output.put_line('LANG=' || v_lang);
9 select sid, serial# into v_sid, v_serial#
10 from v$session where audsid=userenv('sessionid');
11 dbms_output.put_line('sid=' || v_sid || ', serial#=' ||
v_serial#);
12* END;
[EMAIL PROTECTED]:SQL>/
Gatilho criado.
[EMAIL PROTECTED]:SQL>insert into dept values(88, 'Dep.88', null, null);
LANG=BRAZILIAN PORTUGUESE
sid=9, serial#=9
1 linha criada.
==> ok, estava na mesma sessão E com os NLS do cliente... Agora altera
a sessão do cliente :
[EMAIL PROTECTED]:SQL>alter session SET NLS_LANGUAGE='AMERICAN';
Session altered.
==> E tomo uma ação que fará a trigger ser disparada :
[EMAIL PROTECTED]:SQL>insert into dept values(89, 'dep 89', null, null);
==> óia o resultado :
LANG=AMERICAN
sid=9, serial#=9
1 row created.
[EMAIL PROTECTED]:SQL>select * from NLS_SESSION_PARAMETERS;
PARAMETER VALUE
------------------------------ ------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY BRAZIL
NLS_CURRENCY Cr$
NLS_ISO_CURRENCY BRAZIL
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT dd/mm/yyyy hh24:mi:ss
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY Cr$
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 rows selected.
==> confere ?????? Então NÃO É que a trigger "saiba" de coisa alguma,
ela SIMPLESMENTE está rodando no mesmo workspace lógico, yes ?? E isso
é VERDADEIRO seja o cliente Forms, sqlplus. Vb, Java, o que for...
[]s
Chiappa
--- Em [email protected], "ESTUDO" <[EMAIL PROTECTED]> escreveu
>
> Chiappa
> e no caso de uma trigger, que no corpo dela tem translate com
inserts, a mesma foi rodada num client nls_lang = brazilian...
>
> PERGUNTA: qdo joaozinho estiver utilizando o programa dele, em
forms, em determinado momento a trigger será disparada, então essa
trigger inserirá nomes de pessoas, com acento, sem acento.. pra isso
ela utilizará qual nls?
>
> Se você me disser que ela usará o
nls_lang=BRAZILIANPORTUGUESE_BRAZIL.WE8MSWIN1252 , como a Trigger sabe
disso?
>
> Obrigada
>
> Cris
>
>
>
>
> ----- Original Message -----
> From: jlchiappa
> To: [email protected]
> Sent: Friday, February 16, 2007 9:34 AM
> Subject: [oracle_br] Re: Nls_lang -- dúvida cruel
>
>
> Colega, não só linguagem, MAS para TODOS os principais componentes
> NLS_nn (independente do gosto...), o comportamento DOCUMENTADO é que
> settings NLS são DITADOS PELO CLIENTE (na prática, o valor do
> servidor é um default que será usados SE e APENAS SE o cliente não
> especificar nada), como nos diz o manual Oracle Database
> Globalization Support Guide, no cap. 1 Overview of Globalization
> Support :
>
> "
> From a globalization support perspective, all applications are
> considered to be clients, even if they run on the same physical
> machine as the Oracle instance. For example, when SQL*Plus is started
> by the UNIX user who owns the Oracle software from the Oracle home in
> which the RDBMS software is installed, and SQL*Plus connects to the
> database through an adapter by specifying the ORACLE_SID parameter,
> SQL*Plus is considered a client. Its behavior is ruled by client-side
> NLS parameters.
>
> Another example of an application being considered a client occurs
> when the middle tier is an application server. The different sessions
> spawned by the application server are considered to be separate
> client sessions.
>
> When a client application is started, it initializes the client NLS
> environment from environment settings. All NLS operations performed
> locally are executed using these settings.
> "
>
> E especificamente no caso do charecter set o mesmo manual nos diz :
>
> ""If the client session and the database server specify different
> character sets, then the Oracle9i database converts character set
> strings automatically.
> "
> ==> então SIM, se vc não quiser que haja conversão implícita em
> princípio CADA INSTALAÇÂO DE CLIENTE deveria seguir um padrão em
> termos de NLS, principalmente de charaterset, sim....
> Claro, quando vc for fazer a conversão vc até PODERIA usar a sintaxe
> de TRANSLATE(argumentos) USING nomedocharactersetaseuusado (cfrme
> mostrado no manual "SQL Reference" para esse item), E pra alguns
> params NLS, como a linguagem para datas, o formato de datas, etc, vc
> indica o que quer já no TO_CHAR/TO_DATE, que o mesmo manual nos
> mostra que aceitam NLS_LANG, formato de data, etc, como argumentos,
> também.
> Notar TAMBÉM que muitos params NLS vc pode setar na sessão via
> ALTER SESSION (ver o mesmo manual "SQL REFERENCE", assim em tese nada
> impede que vc tenha uma trigger de logon aonde FORÇOSAMENTE quando
> alguém se loga no banco a trigger dispara e faz um ALTER SESSION SET
> NLS__xyz = valorquevcquer.... Mas sinceramente : se for ambiente web
> para o cliente é o servidor web, é um lugar só que vc tem que setar,
> E se for ambiente client/server ** NECESSARIAMENTE **, acho eu, quem
> instala o software de cliente Oracle é um TÉCNICO, não um usuário
> final (pois há diversos ajustes a fazer principalmente se será usado
> conexão TNS , o procedimento de instalação em si também não é click-
> click-pronto), então NÂo vejo grande dificuldade em se ter um PADRÂO
> para linguagens, charactersets, locais de instalação, componentes a
> instalar, ** VERSÂO QUE SERÁ USADA **, etc.
>
> []s
>
> Chiappa
>
> --- Em [email protected], "ESTUDO" <estudo2003@>
> escreveu
> >
> > Nls ainda... mas dessa vez é sobre o armazenamendo dos dados !
> >
> > Oracle 9i.
> >
> > Na minha estação de trabalho, tenho o nls_lang=BRAZILIAN
> PORTUGUESE_BRAZIL.WE8MSWIN1252
> >
> > E no servidor tenho nls_lang= AMERICAN_AMERICA.WE8ISO8859P1
> >
> > Da minha estação de trabalho rodo um pl-sql que tira acentos com o
> comando translate.
> > Através do select, vejo que o nome José, ao invés de ficar Jose
> (sem acento), ficou (Josi).
> >
> > **** Caso eu mude na minha estação de trabalho o
> ns_lang=AMERICAN_AMERICA.WE8ISO8859P1 , ocorre tudo certo.
> >
> > Então vem a dúvida: Quando rodo um comando sql, o SGBD grava as
> informações conforme o nls_lang da estação de trabalho, ignorando o
> nl_lang do servidor?
> > Como funciona o armazenamento dos dodos???
> >
> > Pensei que internamente o que prevalecia era o nls_lang do servidor.
> > Se isso for verdade, como testei aqui, não gostei!
> > Pois se temos vários desenvolvedores, se cada um usar um tipo de
> nls_lang, ficará uma hora Josi, outra José, outra Jose .....
> >
> > Obrigada pela atenção
> >
> > Cris
> >
> >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
