Re: [oracle_br] Re: Problema caracter especial

2017-09-27 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Galera,

Muito obrigado pela ajuda na resolução problema!!

Agradeço a todos!!


Atenciosamente,

Rogério Camatini


Em 27 de setembro de 2017 14:47, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> yep, teu teste confirma que a conversão implícita para o characterset do
> banco destino no caso de consulta via dblink ocorre mesmo no sqlplus (não é
> feature do SQL Developer) E que o WE8MSWIN1252 é superset do P1, o que
> permite que todos os caracteres do banco-origem P1 sejam convertidos sem
> falha para exibição no banco-destino 1252okdoc...
>
> []s
>
>   Chiappa
>
> OBS :
>
> nem preciso dizer que se vc for optar pelo caminho de fazer alguma
> Conversão nalgum dos bancos envolvidos a minha Recomendação é que vc
> converta para UNICODE : o 1252 te atende blz neste momento, ele serve para
> todas as linguagens européias Ocidentais (o que inclui o nosso Português
> que vc usa hoje, acredito, bem como alguns diacríticos comuns tipo sinal de
> Euro, de Libra esterlina, de caput, de graus, de frações, etc) mas com a
> Globalização batendo à nossa porta Cedo ou Tarde vc vai ter que armazenar
> caracteres não-europeus ocidentais, então já vale a pena imho se vc for
> migrar já migrar para UNICODE/universal
> 
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-27 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
yep, teu teste confirma que a conversão implícita para o characterset do banco 
destino no caso de consulta via dblink ocorre mesmo no sqlplus (não é feature 
do SQL Developer) E que o WE8MSWIN1252 é superset do P1, o que permite que 
todos os caracteres do banco-origem P1 sejam convertidos sem falha para 
exibição no banco-destino 1252okdoc...

[]s

  Chiappa
  
OBS : 

nem preciso dizer que se vc for optar pelo caminho de fazer alguma Conversão 
nalgum dos bancos envolvidos a minha Recomendação é que vc converta para 
UNICODE : o 1252 te atende blz neste momento, ele serve para todas as 
linguagens européias Ocidentais (o que inclui o nosso Português que vc usa 
hoje, acredito, bem como alguns diacríticos comuns tipo sinal de Euro, de Libra 
esterlina, de caput, de graus, de frações, etc) mas com a Globalização batendo 
à nossa porta Cedo ou Tarde vc vai ter que armazenar caracteres não-europeus 
ocidentais, então já vale a pena imho se vc for migrar já migrar para 
UNICODE/universal

Re: [oracle_br] Re: Problema caracter especial

2017-09-27 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Ou seja, fizeram como eu disse que fariam : Confirmaram a conversão implícita 
para o CHARACTERSET do banco-destino onde vc está conectado em consultas via  
DBLINKs, confirmaram o fato de que o P1 contém Sim caracteres faltantes no P15 
(configurando assim uma IMPEDÂNCIA, uma perda de dados no teu caso de um banco 
P15 consultando um banco P1, devido à falha na conversão implícita de P1 para 
P15) e recomendam vc fazer algum tipo de conversão manual evitando a 
implícita... 

 Só achei que poderiam ter apontado para Notas que ilustrem as OUTRAS 
possibilidades de conversão manual afora a troca de characterset de um dos 
bancos, tais como a UNISTR que eu usei no meu último exemplo (IMHO a melhor 
opção se tua tool de programação/aplicativo/programa-cliente suporta Unicode), 
ou um eventual REPLACE na query que consulta os dados via DBLINK trocando os 
caracteres faltantes no P1 para equivalentes P15 , ou criar uma view e/ou uma 
coluna 'cópia' com os caracteres incompatíveis trocados, ou alterar a coluna de 
VARCHAR2 para NVARCHAR2 (que aí usa o characterset multilanguage definido 
quando da criação do banco, que normalmente é superset de quase TODOS os 
charactersets europeus ocidentais), e coisas assim...

 []s
 
   Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-27 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Muito obrigado pela atenção, tuas informações/testes e etc... foram de
muita utilidade e clareza no problema reportado. Sobre o suporte Oracle
eles recomendaram isso:

CONVERT FROM UTF8 DATABASE TO WE8ISO8859P1 DOES NOT DISPLAY; specially
French E-acute Symbol ( Doc ID 1497181.1

 )

You can use tools like DMU to check for invalid characters converting to
different character sets.

How to Migrate a WE8ISO8859P1 DB to AL32UTF8 using DMU 1.2 - an example ( Doc
ID 1546507.1

 )



Atenciosamente,

Rogério Camatini


Em 26 de setembro de 2017 19:22, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Última forma na minha resposta anterior : Prosseguindo ainda na questão,
> nós vemos que o SQL DEVELOPER é capaz de consultar certinho os dados
> conectando diretamente no banco 8859P1 ** mas ** ao conectar no banco P15 e
> usar dblink criado no banco ISO8859P15 ** não exibe  ** os caracteres P1
> incompatíveis com o CHARACTERSET do banco P15 Isso COMPROVA que o SQL
> Developer tenta ** SIM ** fazer uma conversão implícita, e como vc tem esse
> FURO de ter usado um characterset incompatível na origem do dblink,
> persiste os ? 
>   para PROVAR que o problema é a conversão implícita que ocorre para o
> characterset do banco onde vc tá conectado, dois testes :
>
> T1 : conversão Explícita para UNICODE, veja em
> http://picpaste.com/Query_via_dblink_convert_UNICODE-lVvZG0li.gif que
> convertendo Explicitamente para um characterset SUPERSET tanto do P1 quanto
> do P15 o SQL DEVELOPER exibe TUDO DIREITINHO...
>
> T2 : conversão implícita ocorrendo num database que foi criado com
> characterset superset do ISO8859P1 da origem : no exemplo abaixo criei um
> database com o CHARACTERSET WE8MSWIN1252 que é SUPERSET do P1, crio o
> database link nele E depois conectarei nele :
>
>
> [oracle@ODIGettingStarted ~]$ export ORACLE_SID=DB1252
> [oracle@ODIGettingStarted ~]$ sqlplus system/oracle
>
> SQL*Plus: Release 11.2.0.4.0 Production
>
> Copyright (c) 1982, 2013, Oracle.  All rights reserved.
>
>
> Connected to:
> Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit
> Production
> With the Partitioning, OLAP, Data Mining and Real Application Testing
> options
>
> system@DB1252:SQL> CREATE DATABASE LINK DB1252_TO_DBP1 CONNECT TO SYSTEM
> identified by oracle using 'DBP1';
>
> Database link created.
>
> system@DB1252:SQL> select * from NLS_DATABASE_PARAMETERS where
> parameter='NLS_CHARACTERSET';
>
> PARAMETER   VALUE
> -- 
> NLS_CHARACTERSET   WE8MSWIN1252
>
> system@DB1252:SQL>
>
> ==> veja em http://picpaste.com/Query_via_dblink_from_DB1252-CfCUoa9g.gif
> que a conexão que fiz via dblink nesse database com characterset COMPATÍVEL
> com o P1 tá mostrando Todos os caracteres certinho, agora sim ...
>
> ===>> Então acho que é Isso que o Suporte da Oracle vai te responder no
> teu chamado : quando vc tem uma origem de dados incompatível com o banco em
> que vc está conectado, OU vc converte o banco OU vc faz uma conversão dos
> dados manualmente...
>
> []s
>
>   Chiappa
>
> 
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-27 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Fiz o mesmo teste com uma base que tenho aqui, direto pelo xshell no
servidor AIX e deu o mesmo resultado:

oracle@x:/oracle> sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Wed Sep 27 09:51:10 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application
Testing options

SQL> conn gencel/xx
Connected.
SQL>
SQL> CREATE DATABASE LINK teste CONNECT TO gen_x IDENTIFIED by xxx
USING 'oraac10';

Database link created.

SQL> select sysdate from dual@teste;

SYSDATE
-
27-SEP-17

SQL> select * from gencel.a@teste;

B  ROW_NUM
-- 
°ºª§   row 1
µ  row 2
` á ´  row 3
ç  row 4
|  row 5
¨¢ row 6
¦  row 7

7 rows selected.

SQL> conn / as sysdba
Connected.
SQL> col PARAMETER for a30
SQL> col VALUE for a30
SQL> set lines 200
SQL> select * from NLS_DATABASE_PARAMETERS where
parameter='NLS_CHARACTERSET';

PARAMETER  VALUE
-- --
NLS_CHARACTERSET   WE8MSWIN1252

SQL>


Atenciosamente,

Rogério Camatini


Em 27 de setembro de 2017 09:33, Roger Camatini 
escreveu:

> Chiappa,
>
> Muito obrigado pela atenção, tuas informações/testes e etc... foram de
> muita utilidade e clareza no problema reportado. Sobre o suporte Oracle
> eles recomendaram isso:
>
> CONVERT FROM UTF8 DATABASE TO WE8ISO8859P1 DOES NOT DISPLAY; specially
> French E-acute Symbol ( Doc ID 1497181.1
> 
>  )
>
> You can use tools like DMU to check for invalid characters converting to
> different character sets.
>
> How to Migrate a WE8ISO8859P1 DB to AL32UTF8 using DMU 1.2 - an example ( Doc
> ID 1546507.1
> 
>  )
>
>
>
> Atenciosamente,
>
> Rogério Camatini
>
>
> Em 26 de setembro de 2017 19:22, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Última forma na minha resposta anterior : Prosseguindo ainda na questão,
>> nós vemos que o SQL DEVELOPER é capaz de consultar certinho os dados
>> conectando diretamente no banco 8859P1 ** mas ** ao conectar no banco P15 e
>> usar dblink criado no banco ISO8859P15 ** não exibe  ** os caracteres P1
>> incompatíveis com o CHARACTERSET do banco P15 Isso COMPROVA que o SQL
>> Developer tenta ** SIM ** fazer uma conversão implícita, e como vc tem esse
>> FURO de ter usado um characterset incompatível na origem do dblink,
>> persiste os ? 
>>   para PROVAR que o problema é a conversão implícita que ocorre para o
>> characterset do banco onde vc tá conectado, dois testes :
>>
>> T1 : conversão Explícita para UNICODE, veja em
>> http://picpaste.com/Query_via_dblink_convert_UNICODE-lVvZG0li.gif que
>> convertendo Explicitamente para um characterset SUPERSET tanto do P1 quanto
>> do P15 o SQL DEVELOPER exibe TUDO DIREITINHO...
>>
>> T2 : conversão implícita ocorrendo num database que foi criado com
>> characterset superset do ISO8859P1 da origem : no exemplo abaixo criei um
>> database com o CHARACTERSET WE8MSWIN1252 que é SUPERSET do P1, crio o
>> database link nele E depois conectarei nele :
>>
>>
>> [oracle@ODIGettingStarted ~]$ export ORACLE_SID=DB1252
>> [oracle@ODIGettingStarted ~]$ sqlplus system/oracle
>>
>> SQL*Plus: Release 11.2.0.4.0 Production
>>
>> Copyright (c) 1982, 2013, Oracle.  All rights reserved.
>>
>>
>> Connected to:
>> Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit
>> Production
>> With the Partitioning, OLAP, Data Mining and Real Application Testing
>> options
>>
>> system@DB1252:SQL> CREATE DATABASE LINK DB1252_TO_DBP1 CONNECT TO SYSTEM
>> identified by oracle using 'DBP1';
>>
>> Database link created.
>>
>> system@DB1252:SQL> select * from NLS_DATABASE_PARAMETERS where
>> parameter='NLS_CHARACTERSET';
>>
>> PARAMETER   VALUE
>> -- 
>> NLS_CHARACTERSET   WE8MSWIN1252
>>
>> system@DB1252:SQL>
>>
>> ==> veja em http://picpaste.com/Query_via_dblink_from_DB1252-CfCUoa9g.gif
>> que a conexão que fiz via dblink nesse database com characterset COMPATÍVEL
>> com o P1 tá mostrando Todos os caracteres certinho, agora sim ...
>>
>> ===>> Então acho que é Isso que o Suporte da Oracle vai te responder no
>> teu chamado : quando vc tem uma origem de dados incompatível com o banco em
>> que vc está conectado, OU vc converte o banco OU vc faz uma conversão dos
>> dados manualmente...
>>
>> []s
>>
>>   Chiappa
>>
>> 
>>
>
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-26 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Última forma na minha resposta anterior : Prosseguindo ainda na questão, nós 
vemos que o SQL DEVELOPER é capaz de consultar certinho os dados conectando 
diretamente no banco 8859P1 ** mas ** ao conectar no banco P15 e usar dblink 
criado no banco ISO8859P15 ** não exibe  ** os caracteres P1 incompatíveis com 
o CHARACTERSET do banco P15 Isso COMPROVA que o SQL Developer tenta ** SIM 
** fazer uma conversão implícita, e como vc tem esse FURO de ter usado um 
characterset incompatível na origem do dblink, persiste os ? 
  para PROVAR que o problema é a conversão implícita que ocorre para o 
characterset do banco onde vc tá conectado, dois testes :
  
T1 : conversão Explícita para UNICODE, veja em 
http://picpaste.com/Query_via_dblink_convert_UNICODE-lVvZG0li.gif que 
convertendo Explicitamente para um characterset SUPERSET tanto do P1 quanto do 
P15 o SQL DEVELOPER exibe TUDO DIREITINHO...

T2 : conversão implícita ocorrendo num database que foi criado com characterset 
superset do ISO8859P1 da origem : no exemplo abaixo criei um database com o 
CHARACTERSET WE8MSWIN1252 que é SUPERSET do P1, crio o database link nele E 
depois conectarei nele :  


[oracle@ODIGettingStarted ~]$ export ORACLE_SID=DB1252
[oracle@ODIGettingStarted ~]$ sqlplus system/oracle

SQL*Plus: Release 11.2.0.4.0 Production

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

system@DB1252:SQL> CREATE DATABASE LINK DB1252_TO_DBP1 CONNECT TO SYSTEM 
identified by oracle using 'DBP1';

Database link created.

system@DB1252:SQL> select * from NLS_DATABASE_PARAMETERS where 
parameter='NLS_CHARACTERSET';

PARAMETER   VALUE
-- 
NLS_CHARACTERSET   WE8MSWIN1252

system@DB1252:SQL> 

==> veja em http://picpaste.com/Query_via_dblink_from_DB1252-CfCUoa9g.gif que a 
conexão que fiz via dblink nesse database com characterset COMPATÍVEL com o P1 
tá mostrando Todos os caracteres certinho, agora sim ...

===>> Então acho que é Isso que o Suporte da Oracle vai te responder no teu 
chamado : quando vc tem uma origem de dados incompatível com o banco em que vc 
está conectado, OU vc converte o banco OU vc faz uma conversão dos dados 
manualmente...

[]s

  Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-26 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Blz ? E aí, conseguiu avançar nos testes ? Eu não tenho acesso a um sistema AIX 
mas tive acesso a um Linux, e fiz os testes abaixo, criando um banco com 
characterset WE8ISO8859P1, um outro banco com WE8ISO8859P15 e criando um 
database link do P15 para o P1, simulando mais ou menos o que vc relatou :

==> No servidor com characterset P1, crio a tabela e Insiro os mesmos 
caracteres (incluindo símbolos incompatíveis com o P15), que nem vc tem :


[oracle@ODIGettingStarted oradata]$ export ORACLE_SID=DBP1
[oracle@ODIGettingStarted oradata]$ export NLS_LANG="BRAZILIAN 
PORTUGUESE_BRAZIL.WE8ISO8859P1"
[oracle@ODIGettingStarted oradata]$ sqlplus system/oracle

SQL*Plus: Release 11.2.0.4.0 Production

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

system@DBP1:SQL> create table A (B varchar2(20), ROW_NUM varchar2(20) );

Table created.


==> Crio um database link no banco P15 apontando pro banco P1 :

[oracle@ODIGettingStarted oradata]$ export ORACLE_SID=DBP15
[oracle@ODIGettingStarted oradata]$ export NLS_LANG="BRAZILIAN 
PORTUGUESE_BRAZIL.WE8ISO8859P15"
[oracle@ODIGettingStarted oradata]$ sqlplus system/oracle

SQL*Plus: Release 11.2.0.4.0 Production

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

system@DBP15:SQL> create database link DBP15_to_DBP1 connect to system 
identified by oracle using 'DBP1';

Database link created.

==> Agora vou inserir dados... Vou fazer a inserção pelo SQL DEVELOPER, 
primeiro mostrando que a FONTE em uso é uma que aceita os caracteres em 
questão, veja http://picpaste.com/SQLDEVELOPER_Fonte_TAHOMA-e5IWRt2p.gif para 
confirmar... 
 O insert dos dados foi feito pelo script runner do SQL DEVELOPER, cfrme 
http://picpaste.com/Criar_dados_via_SQLDEVELOPER-VbF2P9z9.gif 
 
 feito isso eu fiz uma Consulta (com os dados pra gente ver os caracteres 
impressos MAS também inclusive DUMPs) veja em 
http://picpaste.com/Query_com_dump_SQLDEVELOPER-y7FQKh82.gif , e depois abri 
conexão no SQL DEVELOPER com o banco P15 (que possui o dblink apontando pro P1) 
e fiz o SELECT via dblink (que nem vc disse), veja em 
http://picpaste.com/Query_com_dump_SQLDEVELOPER_via_DBLINK-uFV3iJch.gif que os 
caracteres são exibidos CERTINHO e que os dados FORAM SIM CODIFICADOS em P1 
 
 []s
 
   Chiappa
   
OBS : só para referência, o SQL Developer que usei é versão 4.1.15.21 64 bits 
rodando na minha máquina pessoal com Windows 8.1 que conecta via rede no 
servidor Linux

Re: [oracle_br] Re: Problema caracter especial

2017-09-22 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bom, primeira coisa como o SQL Developer tá mostrando '?'s pode ser porque a 
FONTE de exibição e/ou o ENCODING não suportam/não contém os caracteres 
originais : após ** confirmar ** que vc está usando uma versão RECENTE do SQL 
Developer (ao menos a 4.1.5), no menu 'Ferramentas' opção Preferências faça os 
seguintes ajustes :

 a. em 'Editor de Códigos' opção Fontes escolha uma Fonte que ** garantidamente 
** tenha os tais caracteres especiais que vc quer exibir : vc vai ter que 
testar mas sei que Tahoma e Segoi são opções com bom suporte a caracteres 
especiais... Notar que AMBAS são proporcionais, então DESMARQUE o checkbox  de 
'Exibir somente Fontes de largura fixa'
 
 e
 
 b. em 'Ambiente' no droplist 'Codificação' escolha uma Codificação apropriada 
: tenta com a mesma codificação origem do database original (ISO-8859-1 se me 
lembro bem), tenta com UTF, e veja lá o que acontece
 
[]s

  Chiappa

 OBS : ao mesmo tempo que vc faz isso, FAÇA TAMBÉM os testes anteriormente 
sugeridos de checar Fonte, Codificação e LOCALE no seu AIX, acessando o sqlplus 
no prompt de comando do AIX...

Re: [oracle_br] Re: Problema caracter especial

2017-09-21 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Segue link da imagem.

http://picpaste.com/dev-DuyzaJya.PNG


Atenciosamente,

Rogério Camatini


Em 6 de setembro de 2017 17:51, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Não, colega : este Fórum ** não suporta ** anexos de qquer tipo : sobe a
> imagem pra um site de Compartilhamento de imagens gratuito qualquer
> (Tinypic, picpaste, imgur, o que vc quiser) e manda pra gente o link...
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Não, colega : este Fórum ** não suporta ** anexos de qquer tipo : sobe a imagem 
pra um site de Compartilhamento de imagens gratuito qualquer (Tinypic, 
picpaste, imgur, o que vc quiser) e manda pra gente o link...

[]s

  Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Hmm, está um pouco mais claro agora : o DUMP tá indicando que vc inseriu as 
strings em WE8ISO8859P1, realmente, E como a nota metalink 121627.1 indicada 
pelo colega registra, alguns caracteres (como hexa A8 e B4) não existem no 
characterset WE8ISO8859P15 que está definido no banco que faz a consulta 
 Como eu tinha dito, eu Acreditava que a conversão para P15 ia resultar na 
exibição do caracter alternativo mas de mesmo código que o P1, mas o exemplo do 
outro colega mostrou que não : sendo assim, penso que vc teria que implementar 
conversão implícita para um characterset que seja um SUPERSET estrito do 
WE8ISO8859P1 : a nota metalink "Changing US7ASCII or WE8ISO8859P1 to 
WE8MSWIN1252 in 8i, 9i, 10g and 11g" (Doc ID 555823.1) diz que o WE8MSWIN1252 é 
:

"WE8ISO8859P1 versus WE8MSWIN1252

All characters included in the WE8ISO8859P1 character set are defined in 
WE8MSWIN1252 with the same codepoint, that means WE8MSWIN1252 is a binary or 
"strict" superset of WE8ISO8859P1.
"

Tenta então fazer os settings TODOS que indiquei (ie, NLS_LANG, LANGUAGE e 
LOCALE no prompt AIX e settings do seu programa de Terminal) apontando para 
WE8MSWIN1252 ao invés do WE8ISO8859P15... 

[]s

  Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Teste feito no SQL DEVELOPER.

[image: Imagem inline 1]


Atenciosamente,

Rogério Camatini


Em 6 de setembro de 2017 16:24, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Eu não tenho aqui uma base teste criada em P1 (sempre usei P15, justamente
> por causa do euro e outros caracteres adicionais), mas sempre acreditei que
> se a raw data presente era x, é o caracter com código ASCII x na tabela do
> characterset configurado que seria exibido, pra mim é Novidade esse
> comportamento que vc mostrou mas ok...
>  Vamos aguardar o colega lá fazer os testes com o SQL DEVELOPER e depois
> ajustando o software de Terminal dele e setando NLS_LANG, Language e
> collate no AIX lá dele, Junto com o DUMP, e vamos ver o que ele obtém... SE
> mesmo com tudo setado certo ele continuar recebendo ? , aí vou pedir pra
> ele indicar um characterset que seja Realmente superset completo do P1,
> provavelmente UNICODE, e vamos ver...
>
>  []s
>
>Chiappa
> 
>


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Segue a consulta da codificação das strings:

SELECT b, DUMP(b, 1016) from a;

B  DUMP(B,1016)
--
--
°ºª§   Typ=1 Len=4 CharacterSet=WE8ISO8859P1: b0,ba,aa,a7
µ  Typ=1 Len=1 CharacterSet=WE8ISO8859P1: b5
` á ´  Typ=1 Len=5 CharacterSet=WE8ISO8859P1: 60,20,e1,20,b4
ç  Typ=1 Len=1 CharacterSet=WE8ISO8859P1: e7
|  Typ=1 Len=1 CharacterSet=WE8ISO8859P1: 7c
¨¢ Typ=1 Len=2 CharacterSet=WE8ISO8859P1: a8,a2
¦  Typ=1 Len=1 CharacterSet=WE8ISO8859P1: a6

7 rows selected.

SQL>


Atenciosamente,

Rogério Camatini


2017-09-06 15:24 GMT-03:00 Luis Freitas lfreita...@yahoo.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Chiappa,
>
>  Achei bem legal a dica do dump, não conhecia essa.
>
>  Mas o comportamento do Oracle quando não há equivalência definida é
> colocar esse ? mesmo, quando não há conversão definida entre os caracteres.
> É fácil de testar isso apenas pelo client, sem passar por um dblink. Ha
> alguns caracteres entre o WE8ISO8859P1 e o WE8MSWIN1252 que tem o mesmo
> problema.
>
>Neste teste a base foi criada usando o WE8ISO8859P1.
>
> SQL> create table teste(x varchar2(10));
>
> Table created.
>
> SQL> insert into teste values ('`');
>
> 1 row created.
>
> SQL> insert into teste values ('´');
>
> 1 row created.
>
> SQL> commit;
>
> Commit complete.
>
> SQL> exit
>
> $ echo $NLS_LANG
> American_America.WE8ISO8859P1
>
> $ sqlplus aaa/bbb
>
> SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 6 15:13:13 2017
>
> Copyright (c) 1982, 2013, Oracle.  All rights reserved.
>
>
> Connected to:
> Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit
> Production
> With the Partitioning, OLAP, Data Mining and Real Application Testing
> options
>
> SQL> select * from teste;
>
> X
> --
> `
> ´
>
> SQL> exit
> Disconnected from Oracle Database 11g Enterprise Edition Release
> 11.2.0.4.0 - 64bit Production
> With the Partitioning, OLAP, Data Mining and Real Application Testing
> options
>
> $ export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
> $ sqlplus aaa/bbb
>
> SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 6 15:13:20 2017
>
> Copyright (c) 1982, 2013, Oracle.  All rights reserved.
>
>
> Connected to:
> Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit
> Production
> With the Partitioning, OLAP, Data Mining and Real Application Testing
> options
>
> SQL> select * from teste;
>
> X
> --
> `
> ¿
>
> SQL>
>
> Atc,
> Luis Freitas
>
>
> On Wednesday, September 6, 2017 2:03 PM, "jlchia...@yahoo.com.br
> [oracle_br]"  wrote:
>
>
>
> Sim, o P15 não é um 'superset' no sentido estrito, pois alguns caracteres
> não estão presentes MAS NOTAR que as posições referentes aos caracteres P1
> diferentes no P15 *** não estão VAZIOS **, e sim ocupados com outros
> caracteres : é o caso dos caracteres hexa A4, A6, B4... CONFIRME que esses
> posições na tabela P15 NÂO ESTÂO VAZIAS, então eu DISCORDO TOTALMENTE que
> numa sessão com P15 como characterset é normal aparecer "?"... O que
> deveria acontecer se a sessão estivesse correta no quesitos NLS é aparacer
> caracteres DIFERENTES, tipo cedilha no lugar do z com acentos do espannhol
> e coisa assim, e ** Não ** o caracter "?", yes ???
>  E da mesma maneira, TANTO no P1 quanto no P15 as posições sem uso
> fixo/pré-determinado/unknow (do hexa 80 at hexa 9F) SÃO AS MESMAS, então se
> fossem esses os caracteres contidos TANTO em p1 quanto em P15 iria aparecer
> um ? , o que ao que entendi lá do colega não é o caso...
>
>  De resto, a nota confirma ** exatamente ** o que eu disse, ie, que vc TEM
> que setar corretamente a variável NLS_LANG (apontando para o CARACTERSET
> P15, se é isso que ele quer exibir), setar o COLLATE/LANGUAGE no
> unix/linux/aix E a config do software de terminal  PRECISAMENTE o que eu
> disse/recomendei...
>
>  E é claro, a nota ** não ** dá a dica do DUMP 1016, que nos mostraria
> TANTO o characterset QUANTO os bytes efetivamente armazenados nessas
> strings
>
>  []s
>
>Chiappa
>
>
> 
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Eu não tenho aqui uma base teste criada em P1 (sempre usei P15, justamente por 
causa do euro e outros caracteres adicionais), mas sempre acreditei que se a 
raw data presente era x, é o caracter com código ASCII x na tabela do 
characterset configurado que seria exibido, pra mim é Novidade esse 
comportamento que vc mostrou mas ok...
 Vamos aguardar o colega lá fazer os testes com o SQL DEVELOPER e depois 
ajustando o software de Terminal dele e setando NLS_LANG, Language e collate no 
AIX lá dele, Junto com o DUMP, e vamos ver o que ele obtém... SE mesmo com tudo 
setado certo ele continuar recebendo ? , aí vou pedir pra ele indicar um 
characterset que seja Realmente superset completo do P1, provavelmente UNICODE, 
e vamos ver...
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Chiappa,
     Achei bem legal a dica do dump, não conhecia essa.
     Mas o comportamento do Oracle quando não há equivalência definida é 
colocar esse ? mesmo, quando não há conversão definida entre os caracteres. É 
fácil de testar isso apenas pelo client, sem passar por um dblink. Ha alguns 
caracteres entre o WE8ISO8859P1 e o WE8MSWIN1252 que tem o mesmo problema.
   Neste teste a base foi criada usando o WE8ISO8859P1.
SQL> create table teste(x varchar2(10));
Table created.
SQL> insert into teste values ('`');
1 row created.
SQL> insert into teste values ('´');
1 row created.
SQL> commit;
Commit complete.
SQL> exit
$ echo $NLS_LANGAmerican_America.WE8ISO8859P1
$ sqlplus aaa/bbb
SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 6 15:13:13 2017
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit 
ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing 
options
SQL> select * from teste;
X--`´
SQL> exitDisconnected from Oracle Database 11g Enterprise Edition Release 
11.2.0.4.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real 
Application Testing options
$ export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15$ sqlplus aaa/bbb
SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 6 15:13:20 2017
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit 
ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing 
options
SQL> select * from teste;

X--`¿
SQL>
Atc,Luis Freitas 

On Wednesday, September 6, 2017 2:03 PM, "jlchia...@yahoo.com.br 
[oracle_br]"  wrote:
 

     Sim, o P15 não é um 'superset' no sentido estrito, pois alguns caracteres 
não estão presentes MAS NOTAR que as posições referentes aos caracteres P1 
diferentes no P15 *** não estão VAZIOS **, e sim ocupados com outros caracteres 
: é o caso dos caracteres hexa A4, A6, B4... CONFIRME que esses posições na 
tabela P15 NÂO ESTÂO VAZIAS, então eu DISCORDO TOTALMENTE que numa sessão com 
P15 como characterset é normal aparecer "?"... O que deveria acontecer se a 
sessão estivesse correta no quesitos NLS é aparacer caracteres DIFERENTES, tipo 
cedilha no lugar do z com acentos do espannhol e coisa assim, e ** Não ** o 
caracter "?", yes ???
 E da mesma maneira, TANTO no P1 quanto no P15 as posições sem uso 
fixo/pré-determinado/unknow (do hexa 80 at hexa 9F) SÃO AS MESMAS, então se 
fossem esses os caracteres contidos TANTO em p1 quanto em P15 iria aparecer um 
? , o que ao que entendi lá do colega não é o caso...
 
 De resto, a nota confirma ** exatamente ** o que eu disse, ie, que vc TEM que 
setar corretamente a variável NLS_LANG (apontando para o CARACTERSET P15, se é 
isso que ele quer exibir), setar o COLLATE/LANGUAGE no unix/linux/aix E a 
config do software de terminal  PRECISAMENTE o que eu disse/recomendei...
 
 E é claro, a nota ** não ** dá a dica do DUMP 1016, que nos mostraria TANTO o 
characterset QUANTO os bytes efetivamente armazenados nessas strings
 
 []s
 
   Chiappa  #yiv5084876523 #yiv5084876523 -- #yiv5084876523ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5084876523 
#yiv5084876523ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5084876523 
#yiv5084876523ygrp-mkp #yiv5084876523hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5084876523 #yiv5084876523ygrp-mkp #yiv5084876523ads 
{margin-bottom:10px;}#yiv5084876523 #yiv5084876523ygrp-mkp .yiv5084876523ad 
{padding:0 0;}#yiv5084876523 #yiv5084876523ygrp-mkp .yiv5084876523ad p 
{margin:0;}#yiv5084876523 #yiv5084876523ygrp-mkp .yiv5084876523ad a 
{color:#ff;text-decoration:none;}#yiv5084876523 #yiv5084876523ygrp-sponsor 
#yiv5084876523ygrp-lc {font-family:Arial;}#yiv5084876523 
#yiv5084876523ygrp-sponsor #yiv5084876523ygrp-lc #yiv5084876523hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5084876523 
#yiv5084876523ygrp-sponsor #yiv5084876523ygrp-lc .yiv5084876523ad 
{margin-bottom:10px;padding:0 0;}#yiv5084876523 #yiv5084876523actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5084876523 
#yiv5084876523activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5084876523
 #yiv5084876523activity span {font-weight:700;}#yiv5084876523 
#yiv5084876523activity span:first-child 
{text-transform:uppercase;}#yiv5084876523 #yiv5084876523activity span a 
{color:#5085b6;text-decoration:none;}#yiv5084876523 #yiv5084876523activity span 
span {color:#ff7900;}#yiv5084876523 #yiv5084876523activity span 
.yiv5084876523underline {text-decoration:underline;}#yiv5084876523 
.yiv5084876523attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5084876523 .yiv5084876523attach div a 
{text-decoration:none;}#yiv5084876523 .yiv5084876523attach img 
{border:none;padding-ri

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Sim, o P15 não é um 'superset' no sentido estrito, pois alguns caracteres não 
estão presentes MAS NOTAR que as posições referentes aos caracteres P1 
diferentes no P15 *** não estão VAZIOS **, e sim ocupados com outros caracteres 
: é o caso dos caracteres hexa A4, A6, B4... CONFIRME que esses posições na 
tabela P15 NÂO ESTÂO VAZIAS, então eu DISCORDO TOTALMENTE que numa sessão com 
P15 como characterset é normal aparecer "?"... O que deveria acontecer se a 
sessão estivesse correta no quesitos NLS é aparacer caracteres DIFERENTES, tipo 
cedilha no lugar do z com acentos do espannhol e coisa assim, e ** Não ** o 
caracter "?", yes ???
 E da mesma maneira, TANTO no P1 quanto no P15 as posições sem uso 
fixo/pré-determinado/unknow (do hexa 80 at hexa 9F) SÃO AS MESMAS, então se 
fossem esses os caracteres contidos TANTO em p1 quanto em P15 iria aparecer um 
? , o que ao que entendi lá do colega não é o caso...
 
 De resto, a nota confirma ** exatamente ** o que eu disse, ie, que vc TEM que 
setar corretamente a variável NLS_LANG (apontando para o CARACTERSET P15, se é 
isso que ele quer exibir), setar o COLLATE/LANGUAGE no unix/linux/aix E a 
config do software de terminal  PRECISAMENTE o que eu disse/recomendei...
 
 E é claro, a nota ** não ** dá a dica do DUMP 1016, que nos mostraria TANTO o 
characterset QUANTO os bytes efetivamente armazenados nessas strings
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Roger, 
  Pela nota "Difference between WE8ISO8859P1 and WE8ISO8859P15 characterset 
(Doc ID 121627.1)", o WE8ISO8859P15 não é um "superset" do WE8ISO8859P1. 
  Então alguns caracteres do WE8ISO8859P1 devem aparecer como o ? mesmo, pois 
não tem conversão.
  Da mesma forma, alguns caracteres do WE8ISO8859P15 devem mudar para ? se você 
tentar passar eles para o WE8ISO8859P1.
   A nota lista os caracteres que estão em conflito, que e incluí o ´. O 
WE8ISO8859P15 tem só `e '.
Atc,Luis Freitas
 

On Wednesday, September 6, 2017 9:00 AM, "jlchia...@yahoo.com.br 
[oracle_br]"  wrote:
 

     Blz - faz as verificações que indiquei que vc deve chegar no resultado 
ok... EM ESPECIAL, não deixe de setar a LANG para o chracaterset 
superset/'maior' dos envolvidos, de descobrir como setar a FONTE no teu 
software de terminal (assegurando que ele está usando uma FONTE que contém ** 
todos ** os caracteres necessários)  E de fazer os ajustes de LOCALE no seu 
prompt do AIX, sendo que se vc usa bash shell, provavelmente vc vai poder 
automatizar eles no .bash_profile
 Não deixa de também fazer o teste de conexão/select dessa tabela com 
caracteres especiais no SQL DEVELOPER, já que por default ele converte tudo pra 
UNICODE, é improvável que haja caracteres não presentes no UNICODE nessas 
strings aí... E esse SELECT ** tem ** que conter também o DUMP das strings , 
pra gente ficar sabendo COMO foi codificada essa string, tipo :
 
 SELECT colunastring, DUMP(colunastring, 1016) from tabelaemquestão
 
 []s
 
   Chiappa  #yiv8900305155 #yiv8900305155 -- #yiv8900305155ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8900305155 
#yiv8900305155ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8900305155 
#yiv8900305155ygrp-mkp #yiv8900305155hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8900305155 #yiv8900305155ygrp-mkp #yiv8900305155ads 
{margin-bottom:10px;}#yiv8900305155 #yiv8900305155ygrp-mkp .yiv8900305155ad 
{padding:0 0;}#yiv8900305155 #yiv8900305155ygrp-mkp .yiv8900305155ad p 
{margin:0;}#yiv8900305155 #yiv8900305155ygrp-mkp .yiv8900305155ad a 
{color:#ff;text-decoration:none;}#yiv8900305155 #yiv8900305155ygrp-sponsor 
#yiv8900305155ygrp-lc {font-family:Arial;}#yiv8900305155 
#yiv8900305155ygrp-sponsor #yiv8900305155ygrp-lc #yiv8900305155hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8900305155 
#yiv8900305155ygrp-sponsor #yiv8900305155ygrp-lc .yiv8900305155ad 
{margin-bottom:10px;padding:0 0;}#yiv8900305155 #yiv8900305155actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8900305155 
#yiv8900305155activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8900305155
 #yiv8900305155activity span {font-weight:700;}#yiv8900305155 
#yiv8900305155activity span:first-child 
{text-transform:uppercase;}#yiv8900305155 #yiv8900305155activity span a 
{color:#5085b6;text-decoration:none;}#yiv8900305155 #yiv8900305155activity span 
span {color:#ff7900;}#yiv8900305155 #yiv8900305155activity span 
.yiv8900305155underline {text-decoration:underline;}#yiv8900305155 
.yiv8900305155attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8900305155 .yiv8900305155attach div a 
{text-decoration:none;}#yiv8900305155 .yiv8900305155attach img 
{border:none;padding-right:5px;}#yiv8900305155 .yiv8900305155attach label 
{display:block;margin-bottom:5px;}#yiv8900305155 .yiv8900305155attach label a 
{text-decoration:none;}#yiv8900305155 blockquote {margin:0 0 0 
4px;}#yiv8900305155 .yiv8900305155bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8900305155 
.yiv8900305155bold a {text-decoration:none;}#yiv8900305155 dd.yiv8900305155last 
p a {font-family:Verdana;font-weight:700;}#yiv8900305155 dd.yiv8900305155last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8900305155 
dd.yiv8900305155last p span.yiv8900305155yshortcuts 
{margin-right:0;}#yiv8900305155 div.yiv8900305155attach-table div div a 
{text-decoration:none;}#yiv8900305155 div.yiv8900305155attach-table 
{width:400px;}#yiv8900305155 div.yiv8900305155file-title a, #yiv8900305155 
div.yiv8900305155file-title a:active, #yiv8900305155 
div.yiv8900305155file-title a:hover, #yiv8900305155 div.yiv8900305155file-title 
a:visited {text-decoration:none;}#yiv8900305155 div.yiv8900305155photo-title a, 
#yiv8900305155 div.yiv8900305155photo-title a:active, #yiv8900305155 
div.yiv8900305155photo-title a:hover, #yiv8900305155 
div.yiv8900305155photo-title a:visited {text-decoration:none;}#yiv8900305155 
div#yiv8900305155ygrp-mlmsg #yiv8900305155ygrp-msg p a 
span.yiv8900305155yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8900305155 
.yiv8900305155green {color:#628c2a;}#yiv8900305155 .yiv8900305155MsoNormal 
{margin:0 0 0 0;}#yiv8900305155 o {font-size:0;}#yiv8900305155 
#yiv8900305155photos div {float:left;width:72px;}#yiv8900305155 
#yiv890030

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Blz - faz as verificações que indiquei que vc deve chegar no resultado ok... EM 
ESPECIAL, não deixe de setar a LANG para o chracaterset superset/'maior' dos 
envolvidos, de descobrir como setar a FONTE no teu software de terminal 
(assegurando que ele está usando uma FONTE que contém ** todos ** os caracteres 
necessários)  E de fazer os ajustes de LOCALE no seu prompt do AIX, sendo que 
se vc usa bash shell, provavelmente vc vai poder automatizar eles no 
.bash_profile
 Não deixa de também fazer o teste de conexão/select dessa tabela com 
caracteres especiais no SQL DEVELOPER, já que por default ele converte tudo pra 
UNICODE, é improvável que haja caracteres não presentes no UNICODE nessas 
strings aí... E esse SELECT ** tem ** que conter também o DUMP das strings , 
pra gente ficar sabendo COMO foi codificada essa string, tipo :
 
 SELECT colunastring, DUMP(colunastring, 1016) from tabelaemquestão
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-06 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Obrigado pelas infos, vou verificar os pontos propostos por ti.


Atenciosamente,

Rogério Camatini


Em 5 de setembro de 2017 16:21, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Bom, dado que o WE8ISO8859P15 é um superset do WE8ISO8859P1, eu diria que
> a NLS_LANG deveria estar setada para "BRAZILIAN 
> PORTUGUESE_BRAZIL.WE8ISO8859P15"...
>
>  De resto, xo entender melhor : esse tal software "xshell 4" é um software
> de acesso ssh E que também tem capacidades de terminal, E com ele vc tá
> abrindo uma sessão no AIX, é isso ??
>  SE for isso, o fato do tal sofware estar rodando no Windows é **
> irrelevante ** para o problema, e é no AIX E no tal software que vc deve
> fazer os settings necessários : faz mito tempo que não uso AIX mas iirc
> linguagem e collate vc configura com variável LANG e variáveis LC_
> mesmo, mais ou menos como mostrado nos links de ref que dei MAS plz checa
> na Documentação e nos sites de AIX pra Confirmar Isso... Já o tal software
> xshell eu ** nunca o usei **, mas normalmente softwares do tipo OU possuem
> configuração de fonte e encoding via menu OU via arquivo de configuração OU
> herdam o que vc configurar no Sistema Operacional - cheque a Documentação e
> o Suporte dele pra descobrir como é isso...
>
>  []s
>
>Chiappa
>
> 
>

Re: [oracle_br] Re: Problema caracter especial

2017-09-05 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Bom, dado que o WE8ISO8859P15 é um superset do WE8ISO8859P1, eu diria que a 
NLS_LANG deveria estar setada para "BRAZILIAN 
PORTUGUESE_BRAZIL.WE8ISO8859P15"... 
 De resto, xo entender melhor : esse tal software "xshell 4" é um software de 
acesso ssh E que também tem capacidades de terminal, E com ele vc tá abrindo 
uma sessão no AIX, é isso ?? 
 SE for isso, o fato do tal sofware estar rodando no Windows é ** irrelevante 
** para o problema, e é no AIX E no tal software que vc deve fazer os settings 
necessários : faz mito tempo que não uso AIX mas iirc linguagem e collate 
vc configura com variável LANG e variáveis LC_ mesmo, mais ou menos como 
mostrado nos links de ref que dei MAS plz checa na Documentação e nos sites de 
AIX pra Confirmar Isso... Já o tal software xshell eu ** nunca o usei **, mas 
normalmente softwares do tipo OU possuem configuração de fonte e encoding via 
menu OU via arquivo de configuração OU herdam o que vc configurar no Sistema 
Operacional - cheque a Documentação e o Suporte dele pra descobrir como é 
isso...
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Problema caracter especial

2017-09-05 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Segue mais informações:

SO dos databases: AIX 7.1
SO terminal: windows 10
Terminal: xshell 4

Test 1

PARAMETER  VALUE
-- 
NLS_CHARACTERSET   WE8ISO8859P1

Test 2

PARAMETER  VALUE
-- 
NLS_CHARACTERSET   WE8ISO8859P1

Test 3

PARAMETER  VALUE
-- 
NLS_CHARACTERSET   WE8ISO8859P15

Test 4

PARAMETER  VALUE
-- 
NLS_CHARACTERSET   WE8ISO8859P15



Atenciosamente,

Rogério Camatini


Em 5 de setembro de 2017 13:48, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Ah, e ** importante ** : além dos ajustes, faça testes pedindo *** DUMPs
> *** das strings em questão pra vc poder ver COMO elas estão sendo
> codificadas lá no banco, E além disso faça testes com o ORACLE SQL
> DEVELOPER, que normalmente já codifica internamente tudo em UTF/Unicode,
> como os softwares feitos em Java o fazem...
>
> []s
>
>   Chiappa
> 
>