Problemas com charset

[RogerioRock 0]

Ola, to aqui dinovo rsrs,bem meu problema e que fiz uma plicasão que gera um arquivo de script para ser executado no banco,a aplicação esta gerando o arquivo mt bem.mas na hora de rodar o arquivo as tabelas ou campos que tenham acentos. da erro pq os aceitos são substituidos por caracteres não imprimeveis.O mas estranho e se eu copiar a e colar a linha no sql plus ela roda sem problemas. o Erro so acontese no sqlplus quando uso @arquivo.sql. As minhas configuraçõs estão corretas com o formato europeu como podem ver abaixo.O oracle e o 10g mt obrigado. PARAMETER VALUE---------------------------------------------------------------- -----------------------------------NLS_LANGUAGE AMERICANNLS_TERRITORY AMERICANLS_CURRENCY $NLS_ISO_CURRENCY AMERICANLS_NUMERIC_CHARACTERS .,NLS_CALENDAR GREGORIANNLS_DATE_FORMAT DD-MON-RRNLS_DATE_LANGUAGE AMERICANNLS_CHARACTERSET WE8MSWIN1252NLS_SORT BINARYNLS_TIME_FORMAT HH.MI.SSXFF AMPARAMETER VALUE---------------------------------------------------------------- -----------------------------------NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AMNLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZRNLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZRNLS_DUAL_CURRENCY $NLS_NCHAR_CHARACTERSET AL16UTF16NLS_COMP BINARYNLS_LENGTH_SEMANTICS BYTENLS_NCHAR_CONV_EXCP FALSE19 rows selected.

[Rafael Costa 0]

Seguinte Rogério,Existem 2 tipos de conjuntos de caracteres: um de armazenamento, que é definido na criação do banco e não é possível alterar, e outro de apresentação, que é definido na variávael de ambiente NLS_LANG. O conjundo de caracteres da criação da base deve ser definido como WE8ISO859P1 e variável de ambiente pode ser definida como AMERICAN_AMERICA.WE8ISO8859P1, sendo que AMERICAN_AMERICA determina a linguagem das mensagens e o WE8ISO8859P1 determina o conjunto de carcteres de exibição.Eu não sei o que o teu scipt faz, mas se o cliente exportar uma base com o conjundo de caracteres de exibição errado, a importação tb sderá errada (com caracteres estranhos), mesmo que o conjundo de caracteres de armazenamento esteja correto. De repente pode ser este o teu problema.Obs.: Eu uso o SO Linux RHEL 4. Para determinar a variável de ambiente: export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1; No windos xp existe um local para a edição de variáveis de ambiente nas propriedades do "meu computador", na aba "avançado".Não sei se já sabias disso, ou se já havia tentado, mas acho que o caminho é mais ou menos por aí!!!Valeu...abraço!!

[alphamek 2]

O Rafael explico direitinho!!!!

 

Para matar sua dúvida, você terá que fazer uma consulta na view nls_database_parameters.

 

Aqui será exibido o tipo de caracter que utilizou na criação do banco de dados.

 

Caso seja WE8ISO8859P1, sem problemas, você pode fazer alterações no NLS em nível de sessão que resolve seu problema.

 

Caso seja outro... terá muitos problemas.

 

Está aparecendo caracteres especiais porque o NLS_LANGUAGE da sua instância está AMERICAN, você pode fazer uma alteração simples como:

 

SQL > alter session set nls_language = "PORTUGUESE";

Que será aceito acentuações normalmente. Porém, como o Rafael disse, veja sempre o conjunto de CARACTER que foi criado no banco de dados. Esse somente recriando o banco de dados para alterar.

 

Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif

[Rafael Costa 0]

Alphamek,Li algo a respeito de este parâmetro ser apenas para as mensagens e não para os dados. Fiz alguns testes e realmente é alterada apenas a linguagem das mensagens. Com certeza não existe problema em o NLS_LANGUAGE ficar como AMERICAN, mesmo pq nas minhas configurações ele está assim e o conjunto de caracteres dos dados está em português, veja abaixo:SQL> show parameter nls_languageNAME TYPE VALUE------------------------------------ ----------- ------------------------------nls_language string AMERICANSQL> select * from rafael.blu;NOME--------------------------------------------------cançãoSQL>No windos existe a variável de ambiente no regedit - local machine -> software -> oracle -> (Existe mais uma pasta que que não lembro o nome) -, chamada nls_lang, que é de onde o client do oracle pega o conjunto de caracteres de exibição. O valor da variável deve estar como BRAZILIAN PORTUGUESE_BRAZIL.WE8ISO8859P1. Mas tem um porém, os dados inseridos pelo linux, ficaram desconfigurados no windows e vice-versa. Ainda não consegui descobrir pq isso acontece!É isso aí, abraços e até mais galera!

O Rafael explico direitinho!!!! Para matar sua dúvida, você terá que fazer uma consulta na view nls_database_parameters. Aqui será exibido o tipo de caracter que utilizou na criação do banco de dados. Caso seja WE8ISO8859P1, sem problemas, você pode fazer alterações no NLS em nível de sessão que resolve seu problema. Caso seja outro... terá muitos problemas. Está aparecendo caracteres especiais porque o NLS_LANGUAGE da sua instância está AMERICAN, você pode fazer uma alteração simples como:

SQL > alter session set nls_language = "PORTUGUESE";

Que será aceito acentuações normalmente. Porém, como o Rafael disse, veja sempre o conjunto de CARACTER que foi criado no banco de dados. Esse somente recriando o banco de dados para alterar. Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif

[alphamek 2]

Rafael,

 

Concordo contigo!!! Fiz os testes aqui tb numa base de teste e realmente a alteração do NLS_LANGUAGE e NLS_TERRITORY não afetou os dados incluidos com acentuação.

 

Porém, existe algumas "pulgas" me incomodando, pois alguns meses atrás alguns desenvolvedores estavam com problemas de acentuação nas cargas que era realizada atráves de arquivos de texto vindo de servidores WINDOWS, fiz os testes agora no mesmo servidor que é UNIX.

 

Na época, alterei os valores de NLS_LANGUAGE e NLS_TERRITORY e resolveu o problema.

 

A configuração da base estava assim:

 

SQL > show parameters nlsNAME								 TYPE		VALUE------------------------------------ ----------- ------------------------------nls_calendar						 stringnls_comp							 stringnls_currency						 stringnls_date_format					  string	  DD-MM-RRRRnls_date_language					stringnls_dual_currency					stringnls_iso_currency					 stringnls_language						 string	  PORTUGUESEnls_length_semantics				 string	  BYTEnls_nchar_conv_excp				  string	  FALSEnls_numeric_characters			   stringnls_sort							 stringnls_territory						string	  BRAZILnls_time_format					  stringnls_time_tz_format				   stringnls_timestamp_format				 stringnls_timestamp_tz_format			  stringSQL > select * from nls_database_parameters;PARAMETER					  VALUE------------------------------ --------------------------------------NLS_LANGUAGE				   AMERICANNLS_TERRITORY				  AMERICANLS_CURRENCY				   $NLS_ISO_CURRENCY			   AMERICANLS_NUMERIC_CHARACTERS		 .,NLS_CHARACTERSET			   WE8ISO8859P1NLS_CALENDAR				   GREGORIANNLS_DATE_FORMAT				DD-MM-RRRRNLS_DATE_LANGUAGE			  AMERICANNLS_SORT					   BINARYNLS_TIME_FORMAT				HH.MI.SSXFF AMNLS_TIMESTAMP_FORMAT		   DD-MON-RR HH.MI.SSXFF AMNLS_TIME_TZ_FORMAT			 HH.MI.SSXFF AM TZRNLS_TIMESTAMP_TZ_FORMAT		DD-MON-RR HH.MI.SSXFF AM TZRNLS_DUAL_CURRENCY			  $NLS_COMP					   BINARYNLS_LENGTH_SEMANTICS		   BYTENLS_NCHAR_CONV_EXCP			FALSENLS_NCHAR_CHARACTERSET		 AL16UTF16NLS_RDBMS_VERSION			  9.2.0.6.020 rows selected.SQL >

Especifiquei os valores NLS_LANGUAGE e NLS_TERRITORY no init.ora da instância e resolveu. O Character set do banco de dados era we8ios8859p1 que é compactivel com acentução latina.

 

Agora não tô entendendo se isso não influêncio, o que modificaram no lado deles que resolveu.

 

OBS: EU MATO UM AINDA!

 

Abraços, http://forum.imasters.com.br/public/style_emoticons/default/assobiando.gif