SC 5.2 + campo select + evento ajax nao funciona

(deepcat) #1

Pessoal, me desculpe se esta situacao eventualmente nao for bug, mas surgiu apos a atualizacao do SC para 5.2

Tenho um campo select chamado {codestado}, neste campo eu capturo o código do estado do IBGE e apresento a SIGLA.

Bom, tá funcionando se eu for lá e clicar, mas se eu colocar em um evento ajax em qualquer campo, tipo, nome do cliente (Evento onfocus por exemplo) e disser nesse e codigo que {codestado}= ‘11’; a rotina nao roda. Simples assim, basta eu colocar isto que dá problema.

Como funcionava antes da atualizacao, agora simplesmente as automacoes ligadas a campos desta maneira pararam. Só funciona se o usuario for lá clicar e fazer a selecao manualmente.

Nao consigo mais setar os valores deste e de outros campos select como era feito antes. Mudou algo neste sentido na nova versão ?

(pessanha) #2

estou com o mesmo problema !

(Carlos Simão) #3

Também estou com o mesmo problema. No meu caso, testei ajax no onchange e não atualiza campos select

(Tiago Kirsten) #4

Esse problema do evento ajax não funcionar já vinha da versão v5.1.018, as vezes tinha que tirar a opção ‘Múltiplos Valores’ as vezes tinha que criar o Sql com um ‘sc_concat’, mas mesmo assim tem vezes que não funciona.

(deepcat) #5

Tiago, até pode ter mesmo na 5.1.0018 bug similar, assim como tambem tenho aqui varias outras que ocorrem ou nao dependendo do SGBD, dos indices, dentre várias outras situacoes.
No caso que comentei acima, funciona direitinho na 5.1.0018 e continuo usando ela até hoje sem problemas que me impossibilitem distribuir minhas aplicacoes. Optei pelo downgrade no mesmo dia pois nao dava para ficar pesquisando como superar mais este erro. Levo 1 dia para criar uma tela e levo 10 para providenciar um “workaround” para um bug.
Entendo que uma ferramenta deste porte precisa ser lapidada continuamente levando bastante tempo, mas hoje, com necessidades como o projeto SPED abrangendo cada vez mas o mercado, tem situacao que se torna insuperável para alguns de nós justamente pela questao de tempo, como eu por exemplo. Comprei esta ferramenta pois ela torna o desenvolvimento mais agil…
Na camada onde atuo, ou meu aplicativo tem automacao suficiente para integrar varias tabelas ao mesmo tempo (pais+estado+municipio via codigo do IBGE) ou minhas aplicacoes viram “programinhas de brinquedo”. Se eu deixar muito complicado para o usuario operar, tem concorrente que consegue deixar simples, mesmo que com outra ferramenta ou plataforma. Tudo bem que com outras ferramentas, mas até onde o usuario ou cliente vê estas diferenças ? Se um usuario achar um programa mais facil que outro, independente de que linguagem for, o que for considerado mais dificil tem poucas chances de permanecer bem no mercado. Complicado isso.
Tem outras formas de se abordar esta problemática dos campos selects, em muitos casos, vale um campo captura que joga uma variavel global que pode ser absorvida pela outra tela de captura que antes de ser setada deve ser zerada e depois outra e outra… + - uns 15 eventos que devem ser escritos interdependentes para resolver um problema como este que mencionei e que nos permita chegar ao mesmo resultado com eles abandonado o select e constituindo mais um workaround, mas, o usuario acha mais complicado, muitos clicks e tal… Jogo duro né ? Se o select estivesse ok dava uns 3 eventos ? Talvez 4 ?
Não sugiro o downgrade a quem já está sofrendo com os novos bugs a algum tempo, pois já devem ter investindo um bom tempo decifrando os porques, mas pra quem pode optar, vale a pena ter uma base de producao com uma mesma versao antiga um pouco mais estável e testar as releases novas em uma base de testes, talvez uma vez por mes, com suas aplicacoes para ver se tudo funciona direitinho e aproveitar os novos recursos que eventualmente funcionem bem.
Da 5 para a 5.1 nao tive muitos problemas, mas esta 5.2 ainda nao consegui superar os problemas. Trabalho hoje com a 5.1.0018 e os problemas que tenho já são conhecidos e todos tem uma receita para serem superados.
Se algum colega detectar que este detalhe do campo select for solucionado, por gentileza, entrem aqui e postem para que possamos explorar mais o SC 5.2.
Obrigado a todos.

(Yuri Esteves) #6

Senhores,

Por acaso os campos que os senhores selecionaram para utilizar os eventos Ajax, algum desses campos estão selecionados na parte do SQL, mais especificamente na parte de “Escolha os campos que são chave primária”.

Aguardo Retorno…

(deepcat) #7

Yuri, nao sao campos de minhas chaves primarias nao.
Mas posso adiantar o meu cenário para tentar ilustrar. Funciona + - assim:
tabela de cadastro de clientes
clientes
-codcliente (pk uk)
-nome
-endereco
-numero
-complemento
-bairro
-cep
-telefone
-pais
-estado
-municipio
-codpais (fk da tabela paises)
-codestado (fk da tabela estados)
-codmunicipio (fk da tabela municipios)
-observacao

Bom, quanto ao tipo, são todas varchar de tamanhos distinhos.
Agora faço o seguinte, durante a inclusao de um cliente (pode ser durante um update tb) a pessoa digita o CEP e uso as configuracoes do SC para que os campos endereco, bairro, estado e municipio sejam setados pelo proprio SC (logo na inclusao o valor padrao para o campo pais é brasil, entao quando chego no CEP o pais já está como brasil e o select dele está posicionado no registro correto quanto ao codigo do bacen)
Após os campos estarem preenchidos meu metodo ajax que ocorre no onfocus do proximo campo tem a responsabilidade de ler os nomes do estado e do municipio e buscar os codigos do IBGE para os mesmos. Até este ponto tudo bem, o que nao consigo fazer no SC 5.2 é atribuir algo do tipo {codestado} = 13 ou até mesmo {codmunicipio}= 00536.
Faço as atribuicoes, mas elas nao só nao se refletem durante o evento nos campos label, como nao persistem nas variaveis no momento do post.
No meu cenario foi isto Yuri. Já na 5.1.0018, tá beleza. Há o fato de ter que rolar uns 2 ou 3 eventos ajax seguidos pois até onde entendemos (ou não) as variaveis setadas da forma como falei nao estao prontas já no onchange do cep, precisa rolar mais alguma coisa pra elas ficarem setadas na sessao (estado e municipio), mas se eu fizer no onchange do CEP e no onfocus do campo seguinte, dá tudo certo. Só lembrando, dá certo no 5.1.0018, no 5.2.005 que foi o ultimo que eu testei, não rolava não.

(system) #8

Complementando a informação do Yuri, seria além de chave primária, chave estrangeira.

(deepcat) #9

Olá Rafael, aproveitando o complemento que voce mencionou, o que mudou neste sentido (chave primaria e estrangeira) no SC 5.2 ?
Tem algo que possamos fazer para funcionar ?
É que continua funcionando na 5.1.0018 entende ? Entao nao sei o que pode estar ocorrendo para nao funcionar na 5.2.
Mas veja, nao utilizei o recurso do SC relacionado a chaves.
Meus campos sao chave estrangeira sim, cada um de uma tabela distinta.