Fórum Atualização dos Dados (Rede) #37583

24/07/2003

0

Pessoal, como fazer para enviar uma mensagem de erro ao usuario na seguinte situação..


Imagina que [u:9e45963e0a]dois ou mais usuarios [/u:9e45963e0a]de um sistema abrissem um mesmo arquivo (Ex: produto codigo 1) e [u:9e45963e0a]cada um tivesse intenções diferentes.[/u:9e45963e0a]

O Primeiro quer fazer uma [b:9e45963e0a]alteração na descrição do Produto;[/b:9e45963e0a]O Segundo quer [b:9e45963e0a]alterar a quantidade do produto.[/b:9e45963e0a]
O Terceiro quer [b:9e45963e0a]excluir[/b:9e45963e0a] o produto cadastrado..

[color=blue:9e45963e0a]Acontece que antes que o primeiro usuario efetuasse a alteração o produto fosse excluido pelo terceiro[/color:9e45963e0a]...


Como fazer para que o primeiro usuário receba uma mensagem quando o mesmo for gravar as alterações (post, commit..) e o arquivo editado ja tenha sido excluido, ou então quando o Terceiro usuário tentasse comfirmar a exclusão fosse avisado que o registro esta sendo editado????


Vi um exemplo situação utilizado o ClientDataSet, mas como fazer isso utilizado ´IBDATASET´. Existe alguma forma de avisar os usuários???? para que o mesmo possa tomar um decisão do que fazer???


Siro

Siro

Responder

Posts

24/07/2003

Afarias

|Como fazer para que o primeiro usuário receba uma mensagem quando
|o mesmo for gravar as alterações (post, commit..) e o arquivo editado ja
|tenha sido excluido, ou então quando o Terceiro usuário tentasse
|comfirmar a exclusão fosse avisado que o registro esta sendo
|editado????

Se vc fizer uma alteração e dar um post no registro, este ficará ´travado´ para os demais usuários, até q haja um commit.

ex:

IBDataSet1.Edit;
IBDataSet1.FieldByName(´campo_tal´).AsString := IBDataSet1.FieldByName(´campo_tal´).AsString;
IBDataSet1.Post;

Os usuários da rede vão receber uma exceção se tentárem efetuar uma alteração no registro, e vc pode tratá-la.


Não posso testar agora nem me lembro bem, más, acredito q o IBX irá retornar uma exceção também quando vc postar as alterações de um registro q foi excluido (pois o RecordsAffected = 0), vc tb poderá tratá-la


T+


Responder

Gostei + 0

24/07/2003

Siro

Acontece que se utilizar apenas o post, pelo pouco que estou entendendo, é como se estivesse utilizando o travamento pessimista ( outro usuario não poderia acessar o arquivo simultaneamente para tentar fazer uma alteração enquanto o registro não for liberado) e isso que não quero, como disse, se for possivel após o usario gravar e dar commit, o outro que ainda não gravou , quando tentar concluir a operação receberia o aviso,( com clientdataset isso e fácil) da forma que me disse o registro seria travado e uma mensagem de [u:8c9560f430]deadlock[/u:8c9560f430] seria gerado pelo sgbd e enviado ao usuario que [b:8c9560f430]tentasse fazer a edição[/b:8c9560f430].E aquela velha historia ´ e se o primeiro usuario fosse tomar um cafezinho deixando o registro aberto...´.

Quanto a [b:8c9560f430]exclusão[/b:8c9560f430] não entendi, como pode perceber não tenho conhecimento suficiente pra certas situações, póis ´não sei ou não tenho onde recorrer´, onde moro não existe ninguem na aréa, por isso conto com a colaboração de todos...


Responder

Gostei + 0

24/07/2003

Afarias

|Acontece que se utilizar apenas o post, pelo pouco que estou
|entendendo, é como se estivesse utilizando o travamento pessimista (
|outro usuario não poderia acessar o arquivo simultaneamente para
|tentar fazer uma alteração enquanto o registro não for liberado)

Correto


|e isso que não quero,

Ah tá, pensei q era o q queria.


|se for possivel após o usario gravar e
|dar commit, o outro que ainda não gravou , quando tentar concluir a
|operação receberia o aviso,( com clientdataset isso e fácil)

Então, use CDS

o que vc pode fazer tb é adicionar outros campos (além da chave primária) na cláusula WHERE. Assim, se o usuário alterasse um dos campos (que estão no WHERE), a atualização não ocorreria -- e vc receberia o mesmo erro do ´delete´. (é assim q funciona no CDS)


|me disse o registro seria travado e uma mensagem de deadlock seria
|gerado pelo sgbd e enviado ao usuario que tentasse fazer a edição.E
|aquela velha historia ´ e se o primeiro usuario fosse tomar um cafezinho
|deixando o registro aberto...´.

Fala sério!


|Quanto a exclusão não entendi,

Faça um teste. Abra o registro em uma máquina. Em outra, exclua este registro. Então, na primeira, altere e tente ´Postar´. Acho q vc receberá um erro. Quando o IBX efetua um Update ou Delete ele recupera um valor ´RecordsAffected´ que informa quantos registros foram alterados ou excluídos. Este valor (pro TIBDataSet/TIBQuery) tem q sempre ser igual a 1. Se for maior vc recebe uma exceção e se for 0 acho q tb.


T+


Responder

Gostei + 0

25/07/2003

Siro

|se for possivel após o usario gravar e
|dar commit, o outro que ainda não gravou , quando tentar concluir a
|operação receberia o aviso,( com clientdataset isso e fácil)

Então, use CDS
[color=blue:c4f0d55f38]Para fazer isso teria que refazer tudo (já tenho muita coisa - só em último caso e obrigatoriamente..)[/color:c4f0d55f38]


|me disse o registro seria travado e uma mensagem de deadlock seria
|gerado pelo sgbd e enviado ao usuario que tentasse fazer a edição.E
|aquela velha historia ´ e se o primeiro usuario fosse tomar um cafezinho
|deixando o registro aberto...´.

Fala sério!

[color=blue:c4f0d55f38]Bom pelo que aprendi,´( se aprendi corretamente) principio de transaçoes; se foi iniciada e não finalizada, apenas os registro confirmados são enxergados em READCOMMITED. Neste caso acho que estaria funcionado como Councurrency ( o registro ficaria bloqueado ate o rapazinho voltar do cafe para liberar com commit ou commitRetainig e ai sim outro usuário poderia fazer outra alteração (acho que isto testei e o retorno que tive foi este)[/color:c4f0d55f38]

|Quanto a exclusão não entendi,

Faça um teste. Abra o registro em uma máquina. Em outra, exclua este registro. Então, na primeira, altere e tente ´Postar´. Acho q vc receberá um erro. Quando o IBX efetua um Update ou Delete ele recupera um valor ´RecordsAffected´ que informa quantos registros foram alterados ou excluídos. Este valor (pro TIBDataSet/TIBQuery) tem q sempre ser igual a 1. Se for maior vc recebe uma exceção e se for 0 acho q tb.

[color=blue:c4f0d55f38]Testei e não funcionou. Até marquei ForcedRefresh = True.
Se tiver uma outra ideia que possa me auxiliar.[/color:c4f0d55f38]

Abraços..


Responder

Gostei + 0

25/07/2003

Afarias

|{...} ficaria bloqueado ate o rapazinho voltar do cafe para liberar com
|commit ou commitRetainig e ai sim outro usuário poderia fazer outra
|alteração

Tudo certo, o problema é o ´rapazinho´ ai :D


|Testei e não funcionou. Até marquei ForcedRefresh = True.
|Se tiver uma outra ideia que possa me auxiliar.

Ok, é verifiquei e realmente a exceção não é gerada, más vc ainda pode verificar a propriedade ´RowsAffected´, por exemplo, no evento AfterPost do seu IBDatabase faça algo tipo:

if IBDatabase1.RowsAffected = 0 then
begin
ShowMessage(´Minha mensagem ao usuário´);
// IBDataSet1.Refresh; ou IBDataSet1.Close; IBDataSet1.Open;
// ou o q vc desejar fazer
end;


e, veja a sujestão que fiz em relação a atualização:

> o que vc pode fazer tb é adicionar outros campos (além da chave
> primária) na cláusula WHERE. Assim, se o usuário alterasse um dos
> campos (que estão no WHERE), a atualização não ocorreria -- e vc
> receberia o mesmo erro do ´delete´. (é assim q funciona no CDS)


T+


Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar