Vou tentar de novo, dizem que a terceira vez é a da sorte : re-re-repito, 
PRIMEIRO descubra como está codificado esse arquivo-texto, depois compare com o 
que o banco espera, CHEQUE a config cliente...

  Bom, vamos tatibitatizar, como dizia meu mestre no Júlia Amália - vamos ver o 
caso de um loader primeiro...
   Veja esse meu exemplo , no meu database tenho :

SQL> select * from NLS_DATABASE_PARAMETERS;

PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   BRAZILIAN PORTUGUESE
NLS_TERRITORY                  BRAZIL
NLS_CURRENCY                   R$
.....
NLS_CHARACTERSET               WE8MSWIN1252
.....
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.5.0

20 linhas selecionadas.

ok, WE8MSWIN1252 é o characterset, reservemos esta informação ... Eu tenho um 
arquivo chamado teste.txt delimitado por TAB, com o seguinte conteúdo :

1[TAB]A letra á
2[TAB]a letra é
3[TAB]a letra ç

como eu disse, eu Carrego o arquivo num editor hexa (eu usei o freeware xvi32 , 
em http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm#download ) e 
obtive :

31 09 41 20 6C 65 74 72 61 20 E1 0D 0A 32 09 61 20 6C 65 74 72 61 20 E9 0D 0A 
33 09 61 20 6C 65 74 72 61 20 E7 0D 0A 

okdoc, nós sabemos (se não é só consultar em http://www.asciitable.com/ ) que 
31 hexa é "1", 09 hexa é TAB, 41 hexa é "A", legal, sabemos que "0D0A" é 

o fim de linha no Windows, vamos ver como estão codificadas as letras 
acentuadas.....
  Consultando na grande net uma fonte que me mostre os caracteres 
(http://en.wikipedia.org/wiki/Windows-1252 para o meu caso)  : maravilha, o 
dump 

mostra "á" como 00E1 , "é" como 00E9 e "ç" como 00E7, a minha tool que gera o 
arquivo-texto tá CERTINHA de acordo com o characterset destino !!!!!! Se não 
estivesse , EU é que tinha que ajustar a tools e/ou o ambiente pra que ficasse, 
tá bem ?????? Eu SEI LÀ se essa tal JTDS tá certa...  CONFIRMADO que o 
arquivo-texto tá codificado legal, eu vou criar uma tabelinha vazia e importar 
por sql*loader :

SQL> create table TAB_COM_ACENTOS(c1 number, c2 varchar2(80) );

Tabela criada.

SQL> exit
Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 
Production
.....

C:\Users\jlchiappa>type teste.ctl
LOAD DATA
INFILE 'teste.txt'
INTO TABLE TAB_COM_ACENTOS
FIELDS TERMINATED BY X'09'
(C1,
 C2)

C:\Users\jlchiappa>sqlldr userid=system/oracle data=teste.txt control=teste.ctl

SQL*Loader: Release 10.2.0.5.0 - Production
.....

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

Atingido o ponto de commit - contagem de registros l¾gicos 3

=> vamos ver o resultado, primeiro com uma tool gráfica que já usa codificação 
do SO, que está em pt-br :

C:\Users\jlchiappa>sqlplusw system/oracle

...

SQL> select * from TAB_COM_ACENTOS;

        C1 C2
---------- --------------------------------------
         1 A letra á
         2 a letra é
         3 a letra ç

SQL> 

==> muito bem, vamos ver o DUMP :

SQL> select c1, c2, dump(c2, 16) from tab_com_acentos;

C1 C2                                                                           
    DUMP(C2,16)
-- 
--------------------------------------------------------------------------------
 ----------------------------------------
1 A letra á                                                                     
   Typ=1 Len=9: 41,20,6c,65,74,72,61,20,e1
2 a letra é                                                                     
   Typ=1 Len=9: 61,20,6c,65,74,72,61,20,e9
3 a letra ç                                                                     
   Typ=1 Len=9: 61,20,6c,65,74,72,61,20,e7

SQL> exit


==> E1, E9 e E7  - que linda é a Tecnologia quando funciona, né não ???? Mas 
agora vamos usar uma tool texto :

C:\Users\jlchiappa>sqlplus system/oracle

....

SQL> select * from TAB_COM_ACENTOS;

C1 C2
-- ------------------------------------------------------------------------
 1 A letra ß
 2 a letra Ú
 3 a letra þ

SQL> exit

===> Não foi bem, mostrou caracteres estranhos... Vamos ver o codepage (já que 
estou em Windows) :

C:\Users\jlchiappa>chcp
P gina de c¢digo ativa: 850

=> Opa, isso não tá bom, xo mudar :

:\Users\jlchiappa>chcp 1252
ágina de código ativa: 1252

==> Agora sim : é só não esquecer de usar uma Fonte de caracteres que tenha os 
acentos (nas propriedades do prompt escolho a Lucida Console, que tem), 

e a consulta fica joinha :

:\Users\jlchiappa>sqlplus system/oracle

.....
QL> select * from TAB_COM_ACENTOS;

C1 C2
-- 
--------------------------------------------------------------------------------
 1 A letra á
 2 a letra é
 3 a letra ç

SQL>


====>>> OKDOC ????? Ou seja, é basicamente uma questão de vc TER CERTEZA que o 
arquivo a carregar está OK, E QUE a Exibição de acentos no seu prompt está 
OK..... Não digo que de repente não seja ESSE o seu problema, o dado tá legal 
mas a config do prompt de comando não está, por isso vc vê ?s .... Faça o dump 
no Oracle, confira que o texto tá codificado OK, confira que o seu prompt tá 
configurado pra acentos... Sacou ????

 No caso do export, eu digo : ele é uma tool de LINHA DE COMANDO, e afaik seu 
SO é linux (aonde NÂO existe a figura do registry, portanto ele lê a 
configuração das vars do ambiente) , veja lá se vc está, Além do prompt ok, com 
as VARIÁVEIS NLS do linux ok, blz ????

  []s

     Chiappa

--- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@...> escreveu
>
> Chiappa,
> 
> Então as tabelas e os dados, foram importados a partir do SQL-Server 2005
> para o Oracle 10g via JTDS, todavia eu envio as tabelas e os dados do
> SQL-Server 2005 diretamente para um esquema do Oracle 10g (que uso como
> repositório temporário), neste esquema os dados são mostrados devidamente
> acentuados, mas quando eu exporto os dados desse esquema via dump ou via
> SQL*Loader, as letras acentuadas com ã,õ,é,á, etc... são mostrados com o
> sinal de interrogação!!!
> 
> Coisa de louco!!!
> 
> Veja a configuração do NLS_PARAMETER do meu banco:
> 
> PARAMETER                                                        VALUE
> ----------------------------------------------------------------
> ----------------------------------------------------------------
> NLS_LANGUAGE                                                     AMERICAN
> NLS_TERRITORY                                                    AMERICA
> NLS_CURRENCY                                                     $
> NLS_ISO_CURRENCY                                                 AMERICA
> NLS_NUMERIC_CHARACTERS                                           .,
> NLS_CALENDAR                                                     GREGORIAN
> NLS_DATE_FORMAT                                                  DD-MON-RR
> NLS_DATE_LANGUAGE                                                AMERICAN
> NLS_CHARACTERSET
> WE8ISO8859P1
> 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_NCHAR_CHARACTERSET                                           AL16UTF16
> NLS_COMP                                                         BINARY
> NLS_LENGTH_SEMANTICS                                             BYTE
> NLS_NCHAR_CONV_EXCP                                              FALSE
> 
> 
> 
> Att,
> --
> Wanderson Barrence
> DBA Oracle 10g/11g
> Analista de Testes - CBTS
> ------------------------------------------------------------------
> MSN: wbarrence@...
> ICQ: 170821994
> Linkedin: http://br.linkedin.com/in/wbarrence
> 
> 
> 
> Em 17 de agosto de 2012 14:38, J. Laurindo Chiappa
> <jlchiappa@...>escreveu:
> 
> > **
> >
> >
> > Releia lá a resposta, friendão : sobre o arquivo de texto, o que eu digo é
> > pra vc abrir ele NUM EDITOR DE TEXTO binário, pra ver qual código de
> > caracter ele gravou para cada uma das letras acentuadas, aí vc compara
> > esses códigos com a codepage do characterset do database, veja lá se está
> > batendo, se não estiver vc tem algum prob de configuração, que
> > PROVAVELMENTE deve ser as vars NLS do seu sessão mal-configuradas, okdoc ??
> > Mas vai por partes, como eu disse : primeiro compare os caharactersets dos
> > databases, depois descubra o que a sessão geradora está enviando/setando
> > (através da NLS_SESSION), vai por partes que vc descobre se o problema está
> > na geração ou na recepção....
> >
> >
> > []s
> >
> > Chiappa
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@>
> > escreveu
> > >
> > > Chiappa,
> > >
> > > Eu estou fazendo a carga de dados via SQL*Loader com o Putty. E nos
> > > arquivos de dados não tem nenhuma informação referente ao enconding.
> > >
> > > Att,
> > > --
> > > Wanderson Barrence
> > > DBA Oracle 10g/11g
> > > Analista de Testes - CBTS
> > > ----------------------------------------------------------
> > > MSN: wbarrence@
> > > ICQ: 170821994
> > > Linkedin: http://br.linkedin.com/in/wbarrence
> > >
> > >
> > >
> > > Em 17 de agosto de 2012 13:47, J. Laurindo Chiappa
> > > <jlchiappa@>escreveu:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Nah, eu ** duvido ** que os params NLS estejam corretos : pra mim, o
> > que
> > > > está acontecendo aí é que talvez vc até tenha os NLS corretos NO
> > DATABASE,
> > > > mas no RDBMS Oracle NECESSARIAMENTE os NLS do cliente se SOBREPÕEM ao
> > do
> > > > database, então se vc tiver NLS incorretos no cliente que gera o
> > > > arquivo-texto OU no ambiente / sessão que vc cria para fazer a carga,
> > como
> > > > é correto esses NLS se sobrepõem aos do database e vc recebe coisas
> > > > trocadas.....
> > > > Outra possibilidade Forte é que os character sets dos dois databases
> > não
> > > > sejam os mesmos : SE isso acontecer e ambos não forem supersets um do
> > > > outro, vão ter conversões aí....
> > > >
> > > > Minha sugestão portanto é :
> > > >
> > > > a. confira os charactersets dos dois databases
> > > >
> > > > b. confira os settings NLS da sessão que gera o arquivo-texto (da
> > SESSÃO,
> > > > não do database), consultando na NLS_SESSION_PARAMETERS a entrada dela
> > > >
> > > > c. tenha CERTEZA que o seu ambiente é capaz de gerar os caracters
> > > > necessários - por exemplo, no prompt DOS do Windows vc ajusta o
> > codepage
> > > > com CHCP, numa tool gráfica isso varia, sendo que algumas GUIs (como
> > por
> > > > exemplo tipicamente algumas feitas em Java) trabalham diretamente com
> > > > Unicode
> > > >
> > > > d. na dúvida sete no seu ambiente as variáveis NLS diretamente para os
> > > > valores apropriados pro seu ambiente, sem confiar em defaults
> > > >
> > > > e. use a função de DUMP tanto no database Oracle origem quanto no
> > destino
> > > > para ver quais os códigos que estão sendo lido/gravados
> > > >
> > > > f. abra o texto num editor Binário, para vc conferir quais códigos
> > estão
> > > > sendo gerados
> > > >
> > > > []s
> > > >
> > > > Chiappa
> > > >
> > > > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@>
> > > > escreveu
> > > >
> > > > >
> > > > > Olá Pessoal,
> > > > >
> > > > > Fiz recentemente uma carga de dados, através do SQL*Loader, nos
> > arquivos
> > > > > que contém os dados, as palavras estão acentuadas corretamente, após
> > a
> > > > > carga de dados, os caracteres como: ç,ã,õ,ó,á, etc... form trocados
> > por
> > > > > sinais de interrogação invertidos!!!
> > > > >
> > > > > Alguém sabe me responder o que está acontecendo? Considerando que o
> > > > > NLS_PAREMETER estão corretos e de acordo com os demais ambientes!!!
> > > > >
> > > > > Att,
> > > > >
> > > > > --
> > > > > Wanderson Barrence
> > > > > DBA Oracle 10g/11g
> > > > > Analista de Testes - CBTS
> > > > > ----------------------------------------------------------
> > > > > MSN: wbarrence@
> > > >
> > > > > ICQ: 170821994
> > > > > Linkedin: http://br.linkedin.com/in/wbarrence
> > > > >
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram removidas]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >  
> >
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>


Responder a