Trigger no Interbase

[LeoSlander]

Alguém sabe se é possivel criar uma trigger no interbase sem deixar código inválido, ou seja, caso você exclua um registro ao cadastrar um novo pegar o código próximo (o que foi excluido por exemplo);

Qualquer informação já ajuda!

[gandalfnho]

Por código você quer dizer a chave primária de uma tabela? Fazer um auto-incremento sem buracos (o que acontece usando generators)? Se sim, dá para fazer, mas só compensa fazer esse tipo de coisa se realmente não pode ter buracos na numeração, tipo para notas fiscais, devido ao trabalho extra que dá, já que é necessário manter um controle dos números livres (dos posts deletados).

[LeoSlander]

Sim a chave primaria de uma tabela usando generators. Justamente o que você falou sem deixar buracos na numeração. Ex inseri 5 clientes o generator vai gerar 1,2,3,4,5, mas se for excluido o 3 por exemplo dai quando eu for inserir o proximo cliente pegar no generator o numero 3.

Da pra fazer?

[gandalfnho]

Usando só o generator não, porque ele não reaproveita os números já usados (para garantir que não haja duplicados). Como eu disse acima, o que você quer dá para fazer, mas requer bastante trabalho e atenção, porque precisa manter um controle dos códigos livres, levar em conta as transações para evitar conflitos e mais outras coisas. Por isso, só vale a pena ter esse trabalho se realmente for necessário evitar os buracos, já que na grande maioria das aplicações não há necessidade disso.

[LeoSlander]

Ok. obrigado pela atençao.

[mthomazs]

Nem requer tanto trabalho. Basta dar um Select Max(campoChave) from tabela into new.CampoChave;

[gandalfnho]

Em ambiente mono-usuário sim, mas num ambiente multi-usuário tem que se levar em conta que se mais de um estiver trabalhando ao mesmo tempo, poderá dar conflito porque ambos pegarão o mesmo número, por isso torna-se mais complicado o processo.

[mthomazs]

Isso só vai depender do tipo de transação que o sistema estiver usando. Se estiver usando Read Commited por exemplo, por mais que se tenha vários usuários gravando ao mesmo tempo, o banco de dados irá sempre pegar o ultimo gravado no select, sendo assim, não irá se repetir.

Outros tipos de transação criam um "espelho" do banco e trabalham com ele até a transação ser encerrada, porém, o Read Commited, pega o estado atual do banco, não deixando gerar conflitos.

[gandalfnho]

Sim, é verdade, mas como o próprio nome do tipo da transação diz ele só lê o que já foi comitado. Exemplo: a transação A inicia e lê 5 como o último número gravado, enquanto ela ainda está ativa, uma segunda transação B inicia e também irá pegar o número 5, já que A ainda não comitou sua gravação. Por isso, que o mais usual é usar generators para esse tipo de tarefa, já que eles não são afetados por transações (um rollback não desfaz o generator) e só evitá-los em casos em que deve-se evitar buracos na numeração, como notas fiscais, devido ao trabalho extra que dá.

[mthomazs]

Posso estar sendo precipitado, mas ele deve estar se referindo a um cadastro, dessa forma, logo após o insert, é dado o commit, não gerando esse problema. Mesmo se não fosse poderia usar uma transação do tipo leitura suja (apesar de não aconselhável), pois ela teria acesso a todas as alterações criadas no banco, não apenas as comitadas.