Após Atualização do SC formulários apresentam erro no modo de inserção

Bugs
#1

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.

Ocorreu um erro!
Erro ao acessar o banco de dados
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘)’ at line 1
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?

#2

Quais os botões que estão sendo exibidos na Barra de Ferramentas desta aplicação.

#3

estou tendo o mesmo problema…

#4

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.

1 Curtida
#5

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)

abraços

#6

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”.

Como o auto-incremento o proprio banco é gerado não vejo necessidade em colocar o campo como Chave Unica.

#7

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.

Ex.:

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.

#8

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

#9

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.

#10

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.

#11

Concordo de pleno.

#12

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?

#13

Agostinho,
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
=)

abraços

#14

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.

#15

aqui as aplicações funcionavam quando abertas através do botão novo da consulta…

já tentou colocar os botões de navegação e mandar ocultar?

#16

Bom Dia, ele existem na tela, nas minhas aplicações de formulario eu deixei eles nao tela, não tirei, por isso meu desespero, porque mesmo tendo la os botoes o erro persiste, se pelo menos gravasse o registro, mas nem isto ocorre e não da erro nenhum, coloquei em modo debug e nada aparece a nao ser esse select count(*)…

#17

É o problema é que os nossos clientes não são iguais aos clientes de NetMake, que esperam, no nosso caso ele dispensam e isso é ruim, pelo menos pra mim, hoje já é sabado dia 23/10 e nada da dita correção, fiz uma gambiarra e tirei o update automatico do campo ID e fiz manual ele no evento beforeinser, pelo menos por enquanto resolveu, hoje o meu cliente trabalha até meio dia e não posso deixar ele mais meio dia parado pela falta de atenção de NetMake que não tem nada a ver com ele…

#18

acredito que a diferença está no fato de que o scriptcase já foi pago, então não adianta reclamar.

lá na empresa aonde trabalho a gente já aprendeu a não atualizar o scriptcase assim que saem essas grandes mudanças (como na versao .15). Na versão 4 a gente ficou 15 dias sem trabalhar pq atualizamos a versão e nada mais funcionava.
Só que dessa vez acabamos atualizando e deu no que deu
=(

#19

Pessoal,

Fica aqui uma lição:

Vejo muitos amigos aqui do fórum reclamando que tem uma aplicação funcionando, ai atualiza a aplicação, recompila de dá pau. O cliente fica parado.

Concordo que a NM tem que tentar evitar mais bugs nas releases.

Agora o bom senso reza, desde os primóridos da INFORMÁTICA, que ao atualizar algo que está funcionando, fazer um backup antes.

Eu quando vou fazer alteração em alguma aplicação, principalmente após atualizar o SC, faço uma cópia da aplicação e trabalho na cópia. Na verdade sempre tenho uma versão da mesma aplicação para melhorias e só mando para a produção após os teste serem bem sucedidos.

Isso evita que o sistema em produção fique parado por erros, bugs ou qualquer outro fator. Quando vou mudar um simples tipo de campo, faço backup antes. Antes de Atualizar o SC, faço um backup antes.

Todo o processo fica mais moroso, mais em caso de qq falha vc não fica sob a mira de uma .40

#20

Cleyton,
na verdade vc já aprendeu a conviver com esses bugs da netmake.

Mas o que vc está falando para ser feito? Tem como voltar uma atualização depois de instalada?

pq não adianta fazer backup da aplicação se o programa que gera os fontes não funciona.