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

Bugs
#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.

#21

Não aprendi a conviver com os problemas do SC. Aprendi a conviver com os problemas da nossa realidade. Utilizo outras soluções de outros fornecedores e acredite, é quase tudo muito parecido.

O cenário ideial é o seguinte:

Vc tem um ambiente de desenvolvimento (DEV), onde vc instala o SC para desenvolver e o ambiente de produção (PROD), onde seu projeto vai rodar na vera.

  1. Nunca substitua uma aplicação no PROD antes de ela estar testada no DEV.

  2. Vc tem uma aplicação no DEV, que já tem uma cópia no PROD e precisa ser alterada. Exporte essa aplicação antes de alterar qualquer coisa nela. Assim, caso algo saia errado vc tem uma cópia do que funcionava sem reconpilação.

  3. Se vc tem acesso ao PROD, fazer uma cópia da aplicação antes de jogar uma cópia de atualização também nunca é demais. Se parar, vc tem uma cópia da aplicação já compilada que funciona.

Tem muitas outras coisas que vc pode fazer para se precaver de desastres. São regras simples, que vc tem que se habituar com elas.

Esqueci de responder a pergunta:

Sempre baixo as versões manualmente. Caso aconteça algo nas releases, reinstalo a ultima mais estável.

#22

Concordo que temos que tomar precauções para evitar esses problemas, mas eu pelo menos parto do principio que a empresa que me fornece a ferramenta é responsavel o suficiente para soltar versões estaveis, e não essa bagunça, o duro que o efeito cascata respinga na gente, para nossos clientes os irresponsaveis somos nós, porque nós confiamos em que não devia, e via de regra é verdade, porque poderiamos efetuar N testes antes de enviar para o cliente o programa, mas vamos e venhamos, conferir todos os programas para ver se existe algum BUG depois da atualização é triste de ser feito hein, ainda mais no dia a dia como o nosso que é um mar em furia o dia todo.

#23

Concordo com quase tudo que disse…

Pq tem que checar todas as aplicações no DEV antes de enviar para o PROD?

Mesmo após uma atualização, o SC só vai gerar código com BUG em aplicações recompiladas na nova release. É ai que vc tem que ter um cuidado especial. Na aplicação que vc está recompilando.

A experiência diz para: não mexer no que está funcionando a não ser que seja preciso. Você não precisa recompilar tudo a cada release. A não ser numa migração de versão quando for o caso. Como foi da V4 para V5 por exemplo.

#24

para voltar uma release anterior vc precisa dos arquivos do sc na release baixados manualmente, e não feito atualização direto pelo sc, a cada release eu baixo manualmente a versão, e antes de instala-la eu faço um backup dos projetos.

Mas o duro é vc estar esperando a release para corrigir um problema, esse problema é corrigido, mas surgem inúmeros outros, por isso sou contra grandes mudanças, prefiro que as novidades venham regularmente, e aos poucos, assim fica mais fácil detectar e corrigir os erros, bugs. Você espera por 1 ano as mudanças, elas vem todas de uma vez, e você passa mais um ano esperando as correções e estabilidade.Dessa forma sentimos que nosso investimento (financeiros no sc) não trazem retorno.

Acho que o fornecedor da linguagem deveria deixar disponível as versões betas, e as releases estáveis, como todo e qualquer empresa de software faz.

E acho também que o fornecedor poderia, ser mais transparente, e disponibilizar em seu site suas intenções quanto as implementações, e também com as sugestões aceitas dos usuários da linguagem, não estou falando de prazos para entrega das implementações, pois prazo em nossa área é algo difícil de cumprir, todos aqui sabem muito bem disso.

Passamos a maior parte do tempo nesse fórum discutindo erros, bugs, do que aprimorando nossos conhecimentos em SC, o fórum já desvirtua bastante, tratando de assuntos que não são específico do SC, dúvidas HTML, JAVASCRIPT, PHP, SQL, Modelagem, o que acaba poluindo e crescendo demais as postagens, sendo que existem foruns especificos para esses outros assuntos. Eu particularmente não respondo a questões que não são SC, salvo algumas exceções.

Particularmente eu gosto da filosofia do SC, e quando alguns paradigmas forem quebrados, acredito que este poderá ser uma das melhores ferramentas de desenvolvimento WEB, desde que mantenha seu foco que é alta produtividade.

#25

Como desenvolvedor, sabemos que é impossível soltar implementações com absolutamente ZERO de erros, eu mesmo tenho que corrigir minhas aplicações, depois de lançadas, pelo fato do usuário (cliente) usar de uma forma que eu não tinha previsto. O que eu acho, é que não se deve criar coisas novas até todos os bugs estarem sanados e se concentrar na correção desses bugs, com velocidade e transparência, estabilizou a release, depois de testada incansavelmente pelo lado do fabricante e pelo lado dos usuários, torna-se essa release como estável (usar o termo estável na release) a partir daí trabalhar em uma nova release beta com uma determinada implementação, paralelamente uma equipe deve sempre estar trabalhando ma melhoria da engenharia interna do código, para a linguagem não virar uma colcha de retalhos.