Olá gente!
Testando a atualização dos campos da chave primária nas versões 7 e 8 do ScriptCase, obtive a seguinte mensagem:
ERRO
Erro ao alterar a base de dados - Registro inexistente
Acredito que isso acontece devido ao fato de serem os valores alterados dos campos da chave que são utilizados na cláusula WHERE, e não os valores originais dos campos da chave.
Então, me parece que a questão aqui é apenas de correção no comando UPDATE.
Ficarei imensamente grato com este ajuste.
Jairo Raiol
Não enxergo erro nisso.
Não se altera chave primaria.
Elas são usadas para a ligação de tabelas no SC e a localização do registro no sc
O senhor está alterando um registro que é chave primaria?
Características de uma Chave Primária :
a - NÂO PODE haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na Chave Primária
b - A chave primária não pode ser composta por atributo opcional , ou seja , atributo que aceite nulo.
c - Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada instância de um entidade.
d - Não devem ser usadas chaves externas. (Atributos sobre os quais você não tem controle. Ex: CPF)
e - Cada atributo identificador da chave deve possui um tamanho reduzido
f - Não deve conter informação volátil.
Gente!
Curto e grosso.
EXEMPLO:
Tabela: faixas
Primary key: id_faixa
Query:
update faixas set id_faixa=‘18-50’ where id_faixa=‘18-45’;
Resultado:
1 row(s) affected Rows matched: 1 Changed: 1 Warnings: 0 0.829 sec
Portanto:
CARACTERISTICAS:
a - NÂO PODE haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na Chave Primária
b - A chave primária não pode ser composta por atributo opcional , ou seja , atributo que aceite nulo.
c - Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada instância de um entidade.
RECOMENDAÇÕES:
d - Não devem ser usadas chaves externas. (Atributos sobre os quais você não tem controle. Ex: CPF)
e - Cada atributo identificador da chave deve possui um tamanho reduzido
f - Não deve conter informação volátil.
SIM Yuri, estou alterando algumas chaves primárias como demonstrado no exemplo acima, e se o sr. tentar fazer isso diretamente no SGBD, também irá conseguir.
CONCLUSÃO:
Caso não consiga realizar o que pretendo, nesta ferramenta, simplesmente deixarei de utilizar o ScriptCase para esta parte do sistema, e passarei a utilizar um FrameWork ou voltarei a fazer no braço como antigamente.
Talvez use o ScriptCase apenas para BI.
Não gastarei mais meu precioso tempo tentando explicar sobre meus trabalhos e sobre limitações e/ou bugs desta ferramenta.
Simples assim.
Grato por qualquer atenção.
Jairo Raiol
Jairo,
No caso quando tu cria um form por exemplo, no lado esquerdo do menu onde diz SQL ele já vem definido e selecionado com * a chave primária lá da tabela e quando aparece essa mensagem abaixo:
ERRO
Erro ao alterar a base de dados - Registro inexistente
A solução é: crie um campo oculto qualquer no form e defina ele como chave primária lá no menu SQL ou defina em um outro campo da tabela uma outra chave primária no form que criou. E verá que esse erro não vai mais acontecer. 
Suas necessidades são suas necessidades, ninguém discute, Se são ou não boas práticas de programação é mais um problema seu.
O SC é um gerador de códigos e para funcionar ele faz coisas internas que não se vê. Por isso ele guarda o valor da chave primária (que no caso está relacionada ao campo) para localizar o registro antes de altera-lo ou excluí-lo por isso o erro de Registro Inexistente.
Quer contornar isso, crie um campo em sua tabela como chave exclusiva, autoincrement e desabilite no item do menu SQL a sua chave primária e habilite esse novo campo como chave e esconda-o, para que o SC possa localizar o registro antes de altera-lo.
Acho que foi essa a sugestão do marcelobs.
Caro Haroldo,
Acredite, com relação a esta sugestão, foi a primeira coisa que tentei fazer, porém, infelizmente, no meu caso não funcionou.
Por que não funcionou?
Perderia o recurso de integridade referencial do banco de dados, o que só funciona com o uso de chaves primárias.
Estou me referindo especificamente sobre o momento da implementação das chaves estrangeiras. Uma chave estrangeira só pode fazer referencia a uma chave primária.
Conclusão:
Algumas vezes eu também dou um jeitinho, gente! Como foi no caso de o SC também ainda não aceitar recursividade em suas ligações, simplemente usei o conceito de recursividade indireta. Porém, para este caso, ainda não encontrei uma forma de contornar esta limitação do SC.
“O único problema que TENHO aqui é a não correção deste BUG”.
“Espero que a equipe de desenvolvedores do SC consiga resolver isso”.
Grato,
Jairo Raiol
Mas não é um BUG. Para mim é aceitável e necessário esse comportamento.
Voce pode colocar um evento onchange, mostrar uma confirmação e caso ok executar seu update via sc_exec_sql, mas terá que redirecionar para a mesma aplicação passando a nova chave para editar o registro que vc acabou de alterar.