Bloqueio De Registro

[Ruyfreis]

Estamos desenvolvendo um programa de Cadastro de clientes, num ambiente de rede.

Como fazer para que enquanto em um terminal estiver sendo tratado o registro (A),

para qualquer operação que não seja leitura, outro terminal somente tenha acesso ao

mesmo (registro A), somente para leitura. Estamos utilizando o BD Firebird e Delphi7.

Aguardamos com urgencia.

Grato.

[Ruyfreis]

Por favor...eu realmete estou precisando disso ...me ajudem...

[s3c]

Colega, também passei por isso e a única solução que encontrei foi uma dica de uma empresa de software que visitava:

1-Crie um campo Lock (inteiro) na tabela que você quiser fazer o lock.

2-Quando você acessar o registro, leia o Lock.

3-Na hora de atualizar, some 1 e regrave o Lock com a cláusula Where Lock = Lock_Lido.

4-Veja se a propriedade RowsAffected da Query retorna 0; se retornar é porque outro terminal atualizou o mesmo registro.

Com isto, o lock se dá na hora da atualização e não na leitura.

[Micheus]

Ruyfreis dê uma olhada neste artigo (link).

Eu utilizo a opção disponível no Firebird 1.5, mensionada no artigo (Select ... From Table [Where ...] [Order By ...] For Update With Lock) e funciona a contento, só tive que fazer uns testes para verificar qual o nível de isolação da transação que deveria utilizar.

[s3c]

Para ser sincero, num ambiente de rede, a opção Update/Lock pode ser uma catástrofe.

Imagine que um terminal dê o Update/Lock e depois a pessoa saia por uma hora sem dar o Commit.

Isso sem falar em dois terminais darem o Update/Lock num mesmo cursor de dados e provocar um deadlock(que é muito comum nesse tipo de travamento de registros).

Já ví diversas discussões sobre esse assunto e na minha opinião, prefiro liberar os registros para todos e na hora de atualizar, somente o primeiro atualiza, forçando os outros a voltar a ler o registro já atualizado.

[Micheus]

Imagine que um terminal dê o Update/Lock e depois a pessoa saia por uma hora sem dar o Commit.

...

Isso sem falar em dois terminais darem o Update/Lock num mesmo cursor de dados e provocar um deadlock

É verdade, são possibilidades. Mas foi uma solução simplista para um sistema pequeno, com poucos usuários e que, para o tipo de aplicação que é, tem funcionado bem.

Mesmo assim, vale apena ler o artigo. Ele não trata apenas da opção que citei (um pouco mais de conhecimento nunca é demais).

[s3c]

É verdade, são possibilidades. Mas foi uma solução simplista para um sistema pequeno, com poucos usuários e que, para o tipo de aplicação que é, tem funcionado bem.

Mesmo assim, vale apena ler o artigo. Ele não trata apenas da opção que citei (um pouco mais de conhecimento nunca é demais).

É sempre bom adquirir conhecimento, mas as vezes os conhecimentos teóricos não andam muito bem na prática e a solução dada foi o que realmente ocorre em ambientes de rede. Como disse, já participei de várias discussões sobre lock de registros e a grande maioria optou pela solução dada. Para um sistema pequeno, onde o Banco de Dados não possui uma grande quantidade de tabelas, as chances de ocorrerem deadlocks são ainda maiores; pois muito facilmente dois terminais acessarão o mesmo cursor de dados com Update/Lock.

[Ruyfreis]

valeu pelas resposta....

Tipo no meu caso é um banco de dados grande que pode ser assessado por muitas pessoas alem de ter muitas tabelas.....

É um programa para a empresa que eu trabalho....

valeu