Bom que agora eu entendi como funciona tudo!!! Att, -- Wanderson Barrence DBA Oracle 10g/11g Analista de Testes - CBTS ------------------------------------------------------------------ MSN: wbarre...@hotmail.com ICQ: 170821994 Linkedin: http://br.linkedin.com/in/wbarrence
Em 20 de agosto de 2012 20:27, Wanderson Barrence <wbarre...@gmail.com>escreveu: > Não acredito que o meu problema era esse "export"? > > Valeu mais uma vez mestre Chiappa. > > Att, > -- > Wanderson Barrence > DBA Oracle 10g/11g > Analista de Testes - CBTS > ------------------------------------------------------------------ > MSN: wbarre...@hotmail.com > > ICQ: 170821994 > Linkedin: http://br.linkedin.com/in/wbarrence > > > > Em 20 de agosto de 2012 19:51, J. Laurindo Chiappa <jlchia...@yahoo.com.br > > escreveu: > > ** >> >> >> Colega, absolutamente não adianta vc colar imagens que o Forum ** não ** >> aceita (por isso sugeri que vc usasse um editor de texto hexa, vc deveria >> ter colado o hex dump, que no caso do xvi é Copy as hex string ), mas de >> qquer maneira é o que eu falei na resposta anterior : primeiro, checar se >> dentro do arquivo tá ok o encoding, segundo olhar no SO, terceiro verificar >> a config NLS do programa client .... Um exemplo no meu ambiente linux de >> teste : >> >> ==> primeiro, os pars NLS do meu banco-destino linux é um pouco >> diferente, veja : >> >> SQL> select * from nls_database_parameters; >> >> PARAMETER VALUE >> ------------------------------ >> ---------------------------------------------------------- >> NLS_LANGUAGE AMERICAN >> NLS_NCHAR_CHARACTERSET AL16UTF16 >> NLS_TERRITORY AMERICA >> .... >> NLS_CHARACTERSET AL32UTF8 >> .... >> NLS_LENGTH_SEMANTICS BYTE >> NLS_NCHAR_CONV_EXCP FALSE >> NLS_RDBMS_VERSION 11.2.0.2.0 >> >> 20 rows selected. >> >> SQL> >> >> ==> okdoc, UTF16 é um superset do WEBISO (no que se refere aos caracteres >> acentuados oeste-europeus , que é o que nos interessa), então seguimos... >> Vamos ver como está o arquivo e o SO : >> >> [oracle@localhost ~]$ cat teste.txt >> >> 1 A letra á >> 2 a letra é >> 3 a letra ç >> >> => blz, perceba que o meu display no linux tá exibindo jóinha os >> caracteres acentuados : SE o seu não exibe, configure-o... No meu caso a VM >> linux que eu uso (a do Oracle developer Days) é acessada com xterm, então >> eu configurei meu terminal na opção Terminal/Set character encoding , se vc >> usa outro terminal, vc provavelmente precisará configurar no seu software >> de terminal... >> Alé, disso, vc precisa setar o LOCALE (ie, as congigs locais) do seu >> Linux, o meu está assim : >> >> [oracle@localhost ~]$ locale >> LANG=en_US.UTF-8 >> LC_CTYPE="en_US.UTF-8" >> LC_NUMERIC="en_US.UTF-8" >> LC_TIME="en_US.UTF-8" >> LC_COLLATE="en_US.UTF-8" >> LC_MONETARY="en_US.UTF-8" >> LC_MESSAGES="en_US.UTF-8" >> LC_PAPER="en_US.UTF-8" >> LC_NAME="en_US.UTF-8" >> LC_ADDRESS="en_US.UTF-8" >> LC_TELEPHONE="en_US.UTF-8" >> LC_MEASUREMENT="en_US.UTF-8" >> LC_IDENTIFICATION="en_US.UTF-8" >> LC_ALL= >> [oracle@localhost ~]$ >> >> => está para UTF-8, que é capaz de exibir todos os caracteres europeus >> ocidentais que nos interessam, então tá... Vamos olhar dentro do arquivo : >> >> [oracle@localhost ~]$ hexdump -c teste.txt >> 0000000 1 \t A l e t r a 303 241 \n 2 \t a >> 0000010 l e t r a 303 251 \n 3 \t a l e >> 0000020 t r a 303 247 \n \n >> [oracle@localhost ~]$ >> >> => o caracter 303 é o "U", o indicador de Unicode, olhando numa tabela de >> caracteres acentuados unicode vc vai ver que tá okdoc .... Configurado ok, >> veja que o file Reconhece a codificação : >> >> [oracle@localhost ~]$ file -b teste.txt >> UTF-8 Unicode text >> >> [oracle@localhost ~]$ file -bi teste.txt >> text/plain; charset=utf-8 >> [oracle@localhost ~]$ >> >> ===> okdoc ??? Então, se o seu Linux tá mostrando us-ascii (que como nós >> sabemos US=7bits=NÂO MOSTRA/RECONHECE ACENTOS), taí uma das fontes do seu >> "problema", plz corrija isso, setando corretamente o seu LOCALE , o seu >> TECLADO, o seu terminal encoding... Legal ??? >> Mas Não Acabou ainda, veja lá o que vai acontecer quando eu fazer a carga >> : >> >> >> SQL> create table TAB_COM_ACENTOS(c1 number, c2 varchar2(80) ); >> >> Table created. >> >> [oracle@localhost ~]$ cat teste.ctl >> >> LOAD DATA >> INFILE 'teste.txt' >> INTO TABLE TAB_COM_ACENTOS >> FIELDS TERMINATED BY X'09' >> (C1, >> C2) >> [oracle@localhost ~]$ sqlldr userid=system/oracle data=teste.txt >> control=teste.ctl >> >> SQL*Loader: Release 11.2.0.2.0 - Production on Mon Aug 20 18:58:47 2012 >> >> Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights >> reserved. >> >> Commit point reached - logical record count 3 >> >> [oracle@localhost ~]$ sqlplus system/oracle >> >> SQL*Plus: Release 11.2.0.2.0 Production >> .... >> >> SQL> select * from tab_com_acentos; >> >> C1 C2 >> ---------- ---------------------------------------------------------- >> 1 A letra ?? >> 2 a letra ?? >> 3 a letra ?? >> >> => oh, dia, oh, azar, oh, vida.... Passo 1 (arquivo) ok, passo 2 (SO) ok, >> não funcionou ... 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=14: 41,20,6c,65,74,72,61,20,ef,bf,bd,ef,bf,bd >> 2 a letra ?? Typ=1 Len=14: 61,20,6c,65,74,72,61,20,ef,bf,bd,ef,bf,bd >> 3 a letra ?? Typ=1 Len=14: 61,20,6c,65,74,72,61,20,ef,bf,bd,ef,bf,bd >> >> => Não tá bem, não colocou os codes corretos.... O que será que pode ser >> ? Se 1 foi ok, 2 foi ok, *** SÓ PODE SER *** o passo 3 , a config da sessão >> Oracle, sim ???? E que no caso de sqlplus e sql*loader, se faz NAS >> VARIÁVEIS DE AMBIENTE, e DE NADA ADIANTA PARA ISSO o setting do database se >> a tool informa um default qquer , vc TEM QUE acertar o NLS do cliente, tá >> lembrado de tudo isso, que eu já falei e refalei ???? Vamos fazer isso : >> >> SQL> truncate table TAB_COM_ACENTOS; >> >> SQL>exit >> Disconnected from Oracle Database 11g Enterprise Edition Release >> 11.2.0.2.0 - Production >> >> => veja que não está setado NLS : >> >> [oracle@localhost ~]$ env | grep -i NLS >> >> => vou setar , no caso ficando IGUALZINHO ao do database, de modo que os >> defaults que a tool pega da linguagem de instalação do Linux não entrem em >> ação : >> >> [oracle@localhost ~]$ export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 >> >> => agora veja que vai ficar tudo bem : >> >> [oracle@localhost ~]$ sqlldr userid=system/oracle data=teste.txt >> control=teste.ctl >> >> SQL*Loader: Release 11.2.0.2.0 - Production on Mon Aug 20 19:05:08 2012 >> >> Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights >> reserved. >> >> Commit point reached - logical record count 3 >> [oracle@localhost ~]$ sqlplus system/oracle >> .... >> SQL> select * from tab_com_acentos; >> >> C1 C2 >> ---------- ---------------------------------------------------------- >> >> 1 A letra á >> 2 a letra é >> 3 a letra ç >> >> => olha o dump : >> >> SQL> set lines 300 pages 9999 >> >> SQL> select c1, c2, dump(c2, 16) from tab_com_acentos; >> >> C1 C2 DUMP(C2,16) >> ---------- ---------------------------------------------------------- >> ------------------------------------------- >> 1 A letra á Typ=1 Len=10: 41,20,6c,65,74,72,61,20,c3,a1 >> 2 a letra é Typ=1 Len=10: 61,20,6c,65,74,72,61,20,c3,a9 >> 3 a letra ç Typ=1 Len=10: 61,20,6c,65,74,72,61,20,c3,a7 >> >> SQL> >> >> q.e.d. / c.q.d. .... >> >> >> []s >> >> Chiappa >> >> --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@...> >> escreveu >> > >> > Olá Chiappa, >> > >> > Segui os passos conforme você ensinou, e no XVI32, o arquivo é mostrado >> > acentuado corretamente (verifique imagem em anexo), então eu mandei os >> > arquivos para o linux, e dei o comando: file -i nome, e o charset do >> > arquivo está "iso-8859-1", o charset do arquivo ".ctl" está "us-ascii". >> > Sendo que eles foram exportados com a codificação "cp 1252" e "windows >> > 1252" do Oracle SQL Developer?? >> > >> > -- >> > 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 21:04, J. Laurindo Chiappa >> > <jlchiappa@...>escreveu: >> > >> > > ** >> >> > > >> > > >> > > 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 20E9 >> > > 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] >> > > > >> > > >> > > >> > > >> > >> > >> > [As partes desta mensagem que não continham texto foram removidas] >> > >> >> >> > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
