Fala Chiappa, Desculpa demorar um pouco para responder, esses últimos dias aqui na empresa estavam bem corridos, estive de licença médica, etc...
Todavia concordo com tudo o que você falou, em número, gênero e grau, e "acho que não tem como não concordar", mas por via das dúvidas estive analisando também o ambiente em que está configurado o SQL-Server 2000, e verifiquei que os dados já estavam sem a acentuação correta nesta base, então melhor para mim que tive a certeza de que os meus ambientes estão configurados corretamente. Depois daquele problema que tive com characterset de alguns caracteres, eu revisei todas as variáveis de ambiente de todos os meus SO's, e até então estão todos ok. Agora estou tentando convencer a equipe de desenvolvimento utilizar em ambiente de desenvolvimento um SO homologado pela Oracle, já que trabalhamos só com JAVA (mais alguns frameworks) e banco de dados Oracle (e algumas vezes importamos alguns dados do SQL-Server), não tem porque não usar um SO como o: RHEL, OEL ou CentOS, já configuração do characterset na DESENV está UTF8, eu acho que deve ser igual ao do ambiente de Produção que é ISO8859. 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 29 de janeiro de 2013 13:58, J. Laurindo Chiappa <jlchia...@yahoo.com.br>escreveu: > ** > > > Tudo blz, colega ? > Então, primeira coisa na verdade idealmente o que deveria acontecer é que > os ambientes de desenvolvimento, Homologação e Produção deveria é ser > IDÊNTICOS, okdoc - afinal, se não forem, nada impede (por exemplo) dos > desenvolvedores usarem um recurso presente no sistema operacional x deles > mas AUSENTE do sistema operacional y usado em produção, OU de haverem bugs > em x que não aparecem em y, isso sem contar a Dificuldade ** imensa ** > adicional de se ficar administrando SOs diferentes em (certamente) > hardwares diferentes, que precisam ser configurados em modos diferentes, só > tem DESVANTAGEM, bem claramente falando.... O máximo aceitável, imho, seria > que num pior cenário, Desenvolvimento fosse diferente (porque há alguma > tool que eles precisam no SO x não-presente no SO y da produção), mas aí > PROD e HOMO *** TEM **** que serem iguais : é Irracional esperar que uma > "homologação" - com aspas Totais! - feita num SO e/ou hardware diferente da > produção valha um centavo furado..... NO máximo o hardware de HOMO pode ter > menor capacidade que PROD (digamos, HOMO é 1/5 da capacidade de PROD, então > vc homologa com 1/5 dos dados, 1/5 das transações, 1/5 dos usuários, tipo > assim), mas mesmo em cacacidade menor o hardware TEM que ser do mesmo > fornecedor, do mesmo tipo, o So ** TEM ** que ser o mesmo, aí SIM vc está > homologando, caso contrário vc está fazendo uma tarefa "para inglês ver", > algo que não vale um tostão furado na prática.... > Isso posto : é ÓBVIO que existem diferenças entre os SOs, variáveis mudam, > valores a serem introduzidos mudam, charactersets que existem na máquina A > podem não existir/não ter sido instalado em B, sim, sim.... A minha > Recomendação, além da documentação dos SOs envolvidos, é que vc use & abuse > dos Fóruns , FAQs, sites de administradores, etc mas Brasileiros e > Portugueses para os SOs envolvidos, já que Dificilmente sysadmins de língua > inglesa vão mexer em Globalização, Acentuação em pt, e coisas do tipo.... > Lógico que não dá MESMO pra apenas "copiar" não-sei-de-onde para o Linux, > sim... > Relembro também o que já tinha falado antes : variáveis de ambiente > tipicamente são usadas em tools de LINHA DE COMANDO, tools com GUIs > tipicamente são ajustadas em menus de opções, arquivos de config e quetais, > sim ?? > Finalizando, Nem preciso dizer que , se depois de estudar o necessário e > fazer as suas tentativas ainda assim vc não obter os resultados, manda aqui > para o Grupo as informações completas (ie, SO usado completo com versão e > patch level, shell usado, conteúdo das vars de ambiente, configuração de > locales do SO em si - como Linguagem e Configurações Regionais atuais -, > tool cliente usada também completa com versão E config atual, etc) que > eventualmente quem estiver usando o mesmo SO/tool certamente pode e vai te > ajudar, ok ? > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence escreveu > > > > Olá Chiappa, > > > > Desculpe a demora, primeiro quero agradecer pela ajuda, então no caso o > > ideal é que os S.O's dos ambientes de Produção, Homologação, Desenv e de > > máquinas que serão usadas pelas ferramentas, estejam com todas as > variáveis > > de ambiente setadas com os mesmos parâmetros. No caso eu nunca tinha > ouvido > > falar das variáveis LC_ALL, LC_CTYPE e LESSCHARSET, e nem sobre > > configuração de teclado!!!! Vou ler mais em relação ao assunto. > > > > Eu tenho um pouco de dificuldade de lidar com os diferentes tipos de SO > de > > cada ambiente, no caso eu não simplesmente copiar todas a variáveis de > > ambiente e copiar e colar no RHEL né? Deve existir alguma diferença, vou > > dar mais uma pesquisa em relação a isso também. > > > > Att, > > > > -- > > Wanderson Barrence > > DBA Oracle 10g/11g > > Analista de Testes - CBTS > > ---------------------------------------------------------- > > MSN: wbarrence@... > > ICQ: 170821994 > > Linkedin: http://br.linkedin.com/in/wbarrence > > > > > > Em 24 de janeiro de 2013 13:28, J. Laurindo Chiappa > > escreveu: > > > > > ** > > > > > > > > > > Bem, para a info completa (no caso do RDBMS Orace) goto manual de > > > Globalization, mas num vapt-vupt : nos RDBMSs mais comuns (e > ESPECIALMENTE > > > no caso do Oracle) a configuração no que se refere à > > > linguagem/characterset/encoding/etc DEVE ser ajustada no Cliente > (tanto na > > > tool cliente quanto no SO do cliente) para se adequar ao que vc tem NO > > > DATABASE, yes ??? É um processo de dois-passos , Primeiro veja como > está > > > codificado NO DATABASE, depois ajuste o Cliente/ambiente do cliente > para se > > > adequar, ok ? > > > No caso do Oracle, quase que ** TODAS ** as tools nativas do database > (ie, > > > exp/expdp/imp/impdp, sqlldr, sqlplus, rman, etc) são executadas em > linha de > > > comando E respondem à variáveis de ambiente (NLS_xxx) , então o ajuste > > > primeiro para elas vai ser setar as variáveis de NLS, principalmente > > > NLS_LANG, que controla 3 itens, separados por ponto : a Linguagem > (língua > > > em que as msgs serão exibidas, que Depende de quais linguagens foram > > > escolhidas quando da instalação do software Oracle em uso, seja o > client > > > seja o RDBMS, mas Inglês-USA é default e está sempre presente), o > > > Território (o país/região do mundo a ser condiderada como 'local', para > > > símbolos monetários e unidades, isso varia pra cada um E tem relação > com a > > > Linguagem) e finalmente o Characterset (o conjunto > > > de codificação de caracteres).... > > > Após isso ajustado, aí vem o SEGUNDO ajuste acima citado, que é no SO > : vc > > > TEM que se assegurar que o SO/ambiente está usando uma Fonte que > possua os > > > caracteres contidos no teu characterset ** E ** tem que ajustar a > > > CODIFICAÇÃO usada pelo So para "bater" com a do characterset - e > (Óbvio) > > > isso varia TOTALMENTE de acordo com o So do cliente que está > executando a > > > tool... No windows, por exemplo, a Fonte vc ajusta no menu de > properties do > > > prompt DOS e a codificação é via comando CHCP, e no Linux vc setaria as > > > variáveis LANG, LC_ALL, LC_CTYPE e LESSCHARSET - isso pode ter alguma > > > mínima variação dependendo do shell que vc usa, mas via de regra é por > aí, > > > algo muito próximo disso ... Há também, òbvio#2, a questão de AJUSTAR o > > > layout do teclado no SO ao seu teclado em uso, nem sempre o SO detecta > > > corretamente : no Windows isso é feito no applet próprio, e no Linux > vai > > > variar de acordo com o shell/GUI em uso, pode ser kbdconfig, keyb, > varia, > > > veja qual é o seu na sua distro E como o acessar na documentação... > > > > > > ===> IMPORTANTE, vou repetir : via de regra a tool que > > > conecta/exporta/importa os dados no/para o banco Não Roda na mesma > máquina > > > que o servidor Oracle (que no seu caso deve ser o Solaris que vc cita) > : > > > sendo assim, Ululantemente Óbvio que o SO e o ambiente a ser Ajustado > NÂO É > > > o do servidor, mas SIM a máquina aonde a tool cliente roda, yes ???? > > > > > > Ajustes feitos, deve funcionar ok: caso vc precise debugar (ie, digamos > > > que vc ache que ajustou tudo mas estão vindo caracteres diferentes do > > > esperado na tool cliente), o que vc faz aí é Primeiro encontrar uma > > > Representação de aonde estão os caracteres de acentuação na codepage > que vc > > > usa (na wikipedia tem para praticamente todos, > > > http://en.wikipedia.org/wiki/WE8ISO8859P15#Aliases é um exemplo para > > > Europeu-Ocidental) , pedir um dump das strings que o banco tem E do > que a > > > tool está recebendo/enviando (no caso do Oracle é o comando DUMP) e > Então > > > comparara para ver se os códigos estão vindo como o esperado.... SE > isso tá > > > ok mas o SO/tool ainda está representando os caracteres erradamente, é > > > refazer/rechecar a config do SO e do ambiente... > > > > > > []s > > > > > > Chiappa > > > > > > OBS : http://www.joelonsoftware.com/articles/Unicode.html é uma muito > boa > > > fonte sobre a Evolução/história do assunto, e de alguns Conceitos > gerais, > > > vale a leitura... > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence escreveu > > > > > > > > > > > Olá Pessoal, > > > > > > > > Existem alguns problemas que são recorrentes com bases de dados, um > dos > > > > problemas mais comuns aqui na empresa é com as palavras acentuadas > > > > (ã,ç,á,à, etc..) que perdem o acento, ou os acentos são trocados, > > > > principalmente dos dados que são importados de bases heterogêneas > (no meu > > > > caso é o MSSQL), tenho várias tabelas que são importadas todos os > dias, > > > um > > > > outro caso muito recorrente também, é na carga de dados, tanto via > insert > > > > quanto sqlloader, alguns dados acentuados perdem a acentuação. > > > > > > > > Alguém conhece alguma maneira de evitar esse tipo de problema? > > > > > > > > S.O SunOS 5.10 > > > > Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi > > > > > > > > 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] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >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
