Autor Tópico: Após Atualização do SC formulários apresentam erro no modo de inserção (Lida 8235 vezes)
« Online: Outubro 20, 2010, 08:51:38 am »
Após atualizar o SC no último dia 15/10/2010, todos os formulários que recompilei apresentam o erro abaixo no momento de inserção de dados na Base Mysql.
SELECT cod_atendimento, cod_cliente, cod_pessoa_solicitante, cod_pessoa_receptora, cod_tipo_atendimento, cod_tipo_motivo_atendimento, cod_unidade_entidade_geral, cod_pessoa_envolvida, data_atendimento, desc_motivo_atendimento, desc_resposta_atendimento, tipo_situacao_atendimento, data_agendamento_retorno, data_retorno_atendimento, desc_retorno_atendimento, cod_identificador_atendimento from cbs_atendimento WHERE (cod_atendimento =)
O mais estranho de tudo é ki fiz testes aki e os outros formulários que seguem o mesmo padrão e não efetuei nenhuma alteração, funcionam normalmente. Basta recompilar o formulário, sem alterar nada e o mesmo apresenta o Erro.
Alguém pode me Ajudar por favor......Tem alguém com o mesmo problema?
« Responder #1 Online: Outubro 20, 2010, 03:54:48 pm »
Quais os botões que estão sendo exibidos na Barra de Ferramentas desta aplicação.
« Responder #2 Online: Outubro 20, 2010, 07:02:31 pm »
« Responder #3 Online: Outubro 20, 2010, 08:14:24 pm »
Também tive este problema, após a ultima atualização do Scriptcase, todos os formulários regerados ou mesmos novos formularios construidos estão apresentando esse erro. Infelizmente a Netmake não consegue manter um padrão de qualidade em testes. Não é a primeira vez que temos que sofrer e nos virar com nossos clientes, por causa de uma atualização com bugs do Scriptcase.
« Responder #4 Online: Outubro 21, 2010, 12:52:04 am »
Citação de: Yuri Esteves em Outubro 20, 2010, 03:54:48 pm
mesmo problema por aqui, Yuri
o erro acontece nas aplicações do tipo formulário que não usam os botões de navegação (primeiro, anterior, próximo e último)
nesse caso quando o formulário era aberto sem nenhum parâmetro a aplicação era iniciada no modo de inserção
após a atualização essas aplicações não rodam mais, pois, aparentemente, ele tenta passar o valor do campo chave para uma SQL. Uma vez que esse campo está vazio, a SQL (que nem deveria ser executada) fica incompleta, não permitindo a execução do formulário.
se o formulário for chamado através de uma ligação da consulta, aí sim com um valor definido para o campo chave, a tela funciona normalmente.
esse erro acontece tanto para as aplicações já existentes que foram recompiladas quanto para as novas aplicações. (digo isso pq o pessoal do suporte já me pediu pra refazer várias aplicações, pois alguns bugs só aconteciam em aplicações já existentes)
« Responder #5 Online: Outubro 21, 2010, 09:24:43 am »
Exatamente Batrol, o erro é o seguinte: O Scriptcase realizar um controle do Select de acordo com os botões de Navagação exibidos, quando os botões são removidos o scriptcase auto detectar que voce ira fazer um controle da sua chave primaria. Quando a aplicação é executada sem os botões de navegação é gerado um input pedindo o valor da chave primaria, caso não informado o erro acontece, iremos lançar uma release provavelmente a release 5.1.018 contendo esta correção.
OBS: Algumas pessoas estão colocando o campo Chave primaria (auto-incremento automatico ou manual) como Chave Única, selecionando apenas esse campo, não vejo muita logica colocar esse campo como chave unica, pois o conceito de chave unica é para não deixar inserir valores repetidos, exemplo "cpf iguais".
« Responder #6 Online: Outubro 21, 2010, 10:09:59 am »
Eu resolvo esse problema ocultando os botões de navegação e não TIRANDO eles da barra de ferramentas.
Uma outra solução que uso é iniciar um formulário com uma variável na WHERE.
Um formulário de cadastro de clientes. Na tabela a PK é CodCLiente
No formulário, na WHERE eu faço CodCliente = [var_controle]
No onExecute do MENU eu faço [var_controle] = 0
Isso força o formulário a abrir sempre em modo NOVO. Quando eu preciso que o formulário volte para o cadastro após a inserção, mando gravar a variável [var_controle] no campo código do cliente no frm.
A esplanação que o Yuri deu abaixo não é bug - ou erro de conceito - de release recente. Desde que uso o SC4, se tirar os botões de navegação da barra, abre com imput pedindo a PK.
« Responder #7 Online: Outubro 21, 2010, 05:17:12 pm »
legal Yuri, ficamos no aguardo de uma atualização pra ver se resolve
Cleyton, boa idéia essa de ocultar os botões. Vou ver se resolve no meu caso aqui.
e o erro aconteceu após a atualização pra versão 5.1.015
as aplicações que funcionavam apenas pararam de funcionar.
essa input pedindo o código a que vcs se referem é naquela aplicação _teste?
ali mesmo, se vc deixasse o campo em branco ele chamava a aplicação em modo de inserção
« Responder #8 Online: Outubro 21, 2010, 05:45:36 pm »
Então batrol, se vc apenas ocultar os botões o SC ainda enxergar eles e creio eu que o erro não irá acontecer, posto que a explicação do Yuri menciona que o SC "precisa" dos botões.
Vc pode ocultar ou desabilitar, o resultado vai ser o mesmo.
Eu sempre utilizado formulário para cadastro em modo new. Para mim não faz sentido utilizar formulários para apresentar range de registros. Por isso uso a técnica de abrir um formulário em modo new usando uma where; pk = 0 e gravando a variável caso seja preciso retornar ao cadastro efetuado.
Pq faço isso? Assim a aplicação formulário não traz nada na query de inicialização. Usando macro o frm abre em modo new, mas traz todos os registros da tabela, navegando para um new.
« Responder #9 Online: Outubro 22, 2010, 02:09:38 pm »
Cleyton, assim que eu tiver um tempo eu testo as suas sugestões.
Mas assim.. pelo menos aqui pra mim esse erro só aconteceu após atualizar. Ou seja, eu sempre usei as aplicações do tipo formulário sem os botões de navegação e sem precisar ocultá-los.
O fato de a aplicação "precisar" dos botões, mesmo que tenha sido implementado agora, já errado.
Se existe a opção de retirar os botões de navegação, o sistema deveria funcionar sem eles.
« Responder #10 Online: Outubro 22, 2010, 02:22:44 pm »
Concordo de pleno.
Citação de: batrol em Outubro 22, 2010, 02:09:38 pm
« Responder #11 Online: Outubro 22, 2010, 05:53:03 pm »
Boa Noite a todos, comigo aconteceu o mesmo erro em uma tela que ja estava funcionando, precisei apenas incluir um campo novo, inclui, compilei e me ferrei, e com ou sem as barras de navegação o erro persiste, olhei tambem a questão que o Yuri mencionou sobre tem o ID(pk) no campo chave unica, mas não é o meu caso, e sempre vem esse bendito erro e agora to com o cliente parado por conta disto, alguem conseguiu contornar isso usando algum outro artificio?
« Responder #12 Online: Outubro 22, 2010, 07:55:40 pm »
Citação de: Agostinho em Outubro 22, 2010, 05:53:03 pm
por aqui, seguindo o conselho do Cleyton, apenas a inclusão dos botões de navegação no formulário o problema foi resolvido.
mas hj a tarde um amigo meu fez uns testes e descobriu uma forma de contornar o problema:
1. No menu, identifique o número do item correspondente ao formulário a ser aberto
2. no onExecute acrescente o seguinte trecho de código:
if (sc_menu_item == "item_XX"){
sc_apl_conf("nome_do_formulario", "start", "new");
}(item_xx é o código do item do menu / nome_do_formulario é o nome da sua aplicação)
isso irá forçar a aplicação a abrir em modo de inserção, sempre que chamada através do menu.
se for chamada de uma ligação de consulga, para edição, ela abre normalmente para editar.
teste ai e coloque o resultado aqui
« Responder #13 Online: Outubro 22, 2010, 09:02:14 pm »
Obrigado pelo retorno, mas no meu caso o menu abre a consulta primeiro, e na consulta pode ou não vir dados, dai o usuario clica para inserir um novo registro. O estranho é que ele abre em modo de edição a partir disto, o erro ocorre na hora de salvar, e mesmo debugando ele apenas mostra o erro em um select count(*) from tabela where id = , dai nao tem a chave depois do sinal de igual, dai o erro.