Alteração simutaneas de Registros no Firebird
Ola pessoal! Tudo Bem?
Fiz um teste no meu sistema que estou fazendo em Delphi com Firebird 1.0 onde coloquei a propriedade Transaction do IbTransaction como Read Commited e alterando um registro do meu cadastro de Grupos simutaneamente fiquei intrigado pois o ultimo a confirmar foi o que ficou registrado. Ai me veio a pergunta: o Banco ta atualizando dados desatualizados? Lembro que ja fiz esse teste com interbase o resultado foi dead lock...
Falow i Pessoal!!!
Fiz um teste no meu sistema que estou fazendo em Delphi com Firebird 1.0 onde coloquei a propriedade Transaction do IbTransaction como Read Commited e alterando um registro do meu cadastro de Grupos simutaneamente fiquei intrigado pois o ultimo a confirmar foi o que ficou registrado. Ai me veio a pergunta: o Banco ta atualizando dados desatualizados? Lembro que ja fiz esse teste com interbase o resultado foi dead lock...
Falow i Pessoal!!!
Dorivansousa
Curtidas 0
Respostas
Afarias
24/05/2004
1) Se a alteração foi postada e logo em seguida comitada, não há dead-lock
2) Se as transações estão configuradas para WAIT, tb não há dead-lock
T+
2) Se as transações estão configuradas para WAIT, tb não há dead-lock
T+
GOSTEI 0
Dorivansousa
24/05/2004
Valeu afarias...
Mas, e com relacao aos dados, o terminal que gravou por ultimo, sobrepoem os dados reais ou os que ele visualizou (desatualizados)?
A configuração do ibtransaction:
read_committed
rec_version
nowait
Falow i!!!
Mas, e com relacao aos dados, o terminal que gravou por ultimo, sobrepoem os dados reais ou os que ele visualizou (desatualizados)?
A configuração do ibtransaction:
read_committed
rec_version
nowait
Falow i!!!
GOSTEI 0
Afarias
24/05/2004
Isto sempre poderá ocorrer, o DEAD-LOCK ocorre apenas quando tentamos alterar um registro q está sendo alterado no mesmo momento (o usuário alterou antes e ainda não deu o commit)
Mas se o commit já foi dado, vc pode estar vendo um registro desatualizado e poderá atualizar!
Mas não se preocupe, existem pelo menos 2 soluções para isso:::
1) a mais utilizada:: inclua na cláusula WHERE da sua alteração Todos os campos (na verdade apenas aqueles q interessam) -- assim, se um for alterado a atualização falha!
2) crie um campo INTEGER com um nome qualquer (tipo: controle) e, crie uma trigger AFTER UPDATE que atualize o campo com um generator (como se fosse um codigo) -- e inclua este campo no seu WHERE, sendo assim, dai, terá o mesmo efeito q o acima.
então, é só o usuário dar refresh para poder tentar novamente atualizar
T+
-- Dai o usuário tem q dar um ´refresh´ para poder tentar alterar novamente!
Mas se o commit já foi dado, vc pode estar vendo um registro desatualizado e poderá atualizar!
Mas não se preocupe, existem pelo menos 2 soluções para isso:::
1) a mais utilizada:: inclua na cláusula WHERE da sua alteração Todos os campos (na verdade apenas aqueles q interessam) -- assim, se um for alterado a atualização falha!
2) crie um campo INTEGER com um nome qualquer (tipo: controle) e, crie uma trigger AFTER UPDATE que atualize o campo com um generator (como se fosse um codigo) -- e inclua este campo no seu WHERE, sendo assim, dai, terá o mesmo efeito q o acima.
então, é só o usuário dar refresh para poder tentar novamente atualizar
T+
-- Dai o usuário tem q dar um ´refresh´ para poder tentar alterar novamente!
GOSTEI 0