Problemas com Charset no Script Case

Banco de Dados
#1

Bom dia a todos!

Estou com problemas para configurar o ScriptCase e meu Banco de Dados Microsoft SQL Server 2008 R2.

O Problema é que em meu ambiente de produção o banco está configurado com a Collation SQL_Latin1_General_CP850_CI_AI e no Script Case nenhuma opção apresentada consegue interpretar os acentos.

O que vem por default é “Western (ISO-8859-1)” já fiz vários testes e não consigo acertar a configuração…

Alguém já passou por esse problema e conseguiu resolver? Seja modificando no Script Case ou no SQL server?

Desde já agradeço pela atenção de todos!

#2

Utilize no SC o seguinte charset “Unicode (UTF-8)” altere nas configurações das aplicações para este que vai resolver…

#3

O problema de charset está nas string que vem do banco ou nas string dos formulários?
Tente mudar o charset na aplicação para iso-8851-1 ou utf8, mas como seu banco está como latin1 então a correta é iso-8859-1.

Aplicação->Configuração->Charset

#4

Boa tarde Enenha e Almeida, tudo bem com vcs?

Bem, os testes realizados nesse início de tarde foram os seguintes:

1- Configuração do projeto = UTF 8 e Aplicações = UTF8
Resultado negativo, pois tando na hora de gravar no banco de dados e de recuperar as informações os valores (ç ó ã á) estão todos com caracteres estranhos.

2- Configuração do projeto = Western (ISO-8859-1) e Aplicações = Western (ISO-8859-1
Resultado parcialmente positivo, pois na hora de gravar no banco de dados as informações vão corretas para o banco, porém na hora de recuperar as informações as mesmas voltam com caracteres estranhos.

Quanto a minha base de dados que está com “SQL_Latin1_General_CP850_CI_AI”

Vou fazer mais testes e volto logo

#5

Thiago, tive um problema semelhante.
Uso o SC no win7 e vertrigo.

No banco de dados do vertrigo estava UTF8
No SC UTF8
Td OK

Enviei a aplicação pro UOLHOST.

  • BD com UTF8
  • Aplicação UTF8
  • Problemas na acentuação.
  • Se criasse, no SC, uma conexão ao UOLHOST, a acentuação tb dava problemas.
    Tava uma zona.

O que eu faço hj e funciona legal. Pode não ser a melhor técnica, mas funciona.

  • No BD do UOLHOST latin_1_general_ci
  • Na aplicação ISO_8859-1.
    Td show de bola.

O problema é que nos testes em localhost, fica uma bagunça, pois mesmo mudando no vertrigo pra latin_1_general_ci, fica bagunçado.

Então, deixo o vertrigo com utf8, faço todos os testes no SC com o utf8 e antes de publicar, entro em cada uma das aplicações e mudo pra iso_8859-1.

Da um bom trabalho, mas testo bastante antes de publicar, para não ter que ficar alterando/ajustando. hehehe

Quando sobrar um tempo vou dar mais uma estudada e informo os resultados.
Mas o que eu notei foi que no ambiente de desenvolvimento que tem a incompatibilidade.

Espero ter ajudado um pouco.

[]s

#6

Cara essa poha de charset é uma increnca…

Thiago, tive um problema semelhante com o teu. Havia criado um banco como utf8 e no sc configurei como iso-8859-1, então zica. Fui no banco e mudei para iso-8859 eeee zica dinovo, oque tive que fazer, criar um novo banco de dados desde o inicio como iso-8859-1 ai funcionou com um projeto criado desde o início como iso-8859-1, então com utf8 deve ser semelhante. Crie algo desde o início nos mesmos formatos para fazer o teste, se possível use suas tabelas do seu banco com erro, mais criando-as com formato correto.

Espero estar ajudando, pois meu conhecimento sobre essas merda de charset é pouco.

#7

Galera se você cria um banco com charset UTF-8 e alimenta ele e depois precisa trocar simplesmente trocar o charset no banco não vai acertar os dados contidos nele é preciso extrair os dados criar um banco com charset desejado e importar os dados novamente.

Outra coisa no apache tem uma configuração que se chama AddDefaultCharset UTF-8 esse cara sempre manda o UTF-8 como codificação padrão para qualquer página, isso causa problemas então vá no conf.ini do seu apache e comente esta linha:

#AddDefaultCharset UTF-8

Reinicie o apache e pronto, alguns problemas de charset podem ser resolvidos somente com isso.

[RESOLVIDO] Dados em ISO-8859-1 e página em UTF-8
#8

Essa paradinha do apache ai eu não sabia, deve ser interessante, vou dar uma olhada .

Vlw a dica aew.

#9

Efetuei esse “comentário” do Saulo e foi a salvação da lavoura.

[]s
Jorge

#10

Campo definido como Editor HTML esta dando problema com acentuação, isso na versão 7.01.0004, atualizei para esta versão, ai eu precisei fazer umas alterações em um form que usa este tipo de campo e ai começou a dar problema. O interessante é que antes da atualização estava tudo normal, funcionando bonitinho.
Ai fui testar outro form que só gerei o fonte e neste form também tem campo editor html e adivinha, problema na acentuação.
Na duvida, mudei o campo para tipo Text e a acentuação funcionou, voltei para editor html e pau.

#11

Estou com o mesmo problema de caracter na versão 7.01.0004, quando usa o editor html, projeto, aplicação e banco tudo em UTF-8, somente em campo editor html, campos texto normal funcionando normalmente.

A Netmake precisa corrigir este bug urgente!

Obrigado.

#12

Urgente

#13

Bom dia, Leandro Coelho.

Acabei de falar com o Yuri da Netmake e já identificaram o bug, ainda esta semana estarão disponibilizando uma release com a correção.

Assim que resolvido, posto a solução aqui.

Abraços.

#14

Ola…

As minhas configurações são as seguintes:
Configuração do projeto = Western (ISO-8859-1) e Aplicações = Western (ISO-8859-1)
Banco de dados MySql está em latin_1_general_ci

No formulário está com erro de Data too Long quando tem acentos no campo e for atualizar.
Agora está com esse novo erro :
Erro ao alterar a base de dados:
Incorrect string value: '\xE1 \xE9 \xE7 ’ for column ‘Nome’ at row 1

Se fizer um update manual na interface do MYSql com acentos funciona normal, quando esses dados são exibidos no form do SC ele vem todos esquisitos.

Uso SC versao 7 com Windows 8, e não achei o arquivo conf.ini indicado pelo Saulo para alterar as configurações do apache e comentar a linha #AddDefaultCharset UTF-8.

Muitas pessoas usam as configurações que estou usando acima e dizem não ter problemas.
Que configurações devo usar para uso local ou host sem ter que mudar e mexer em nada? que funcione nos 2 ambientes.

Obrigado.

#15

Você falou tudo menos o ambiente que você esta rodando o SC. Essa configuração do apache fica no http.conf em algumas distribuições.

#16

Sr(s), bom dia.

Estou com um problema parecido e não sei mais oq alterar.

Coloquei em tudo o Charset utf8 (Amb de producao, banco e tabelas, formulários, inclusive na conexão do SC e no setup após a publicação _lib/). No ambiente de produção funciona que é uma beleza. mas quando coloco o mesmo projeto no cliente que tem as mesmas configurações os forms que possuem campo select na hora de mostrar os dados não exibe os nomes (dos clientes) que tem acentuação, deixando espaços em branco no select.
Fiz um teste e removi a acentuação direto no banco do cliente e funciona.

Não consigo entender uma vez que no cliente o servidor é o mesmo SC e mysql que instalei na minha maquina, copiei tudo o banco da minha maquina para o cliente e da pau! oq acontece? pq na minha maquina roda e na do cliente não?

PS: Esta tudo funcionando normalmente, após uma atualização que fiz no SC que começou essa caca a 4 semanas e nao consegui resolver.

Abraço!

#17

Ambiente de Produção eh o ambiente do Cliente.

Ambiente de Desenvolvimento é o o ambiente do SC.

Edite a conexão no ambiente de conexão e aplique o collate na opção avançado.

#18

Ola Haroldo, já fiz isso

(Amb de producao, banco e tabelas, formulários, inclusive na conexão do SC e no setup após a publicação _lib/)

da na mesma.

#19

inspecione o cabe;calho html e veja se esta igual ao colate dobanco

#20

Haroldo,

Fui acessei a pasta da aplicação e editei o arquivo index.html, lá esta realmente esta errado (charset=ISO-8859-1").
Agora pq? uma vez que ja configurei no form como utf8 tbm?

ABs

form_tb_caixa_contas_a_pagar