DOIS USUARIO EDITANDO UM CADASTRO AO MESMO TEMPO
Olá pessoal, preciso de uma rotina que impeça que mais de um usuário edite ao mesmo tempo um Cadastro..
ou seja, o usuário X esta com um cadastro de Maria da silva na tela, Então o Usuário Y, nao poderá editar o mesmo...
dando um msgbox de aviso....
uso o db mysql
ou seja, o usuário X esta com um cadastro de Maria da silva na tela, Então o Usuário Y, nao poderá editar o mesmo...
dando um msgbox de aviso....
uso o db mysql
Cara.
Essa dica é do Marcelo-Treze.
Gravei ela, pois achei interessante a imposição em que um sistema em rede impõe necessidades, em que o programador
tem que se virar, pra que não digam que seu sistema não é bem bolado e todos fiquem felizes.
Se funfar, todos os créditos são do mano [txt-color=#e80000][txt-size=2]Marcelo-Treze[/txt-size][/txt-color], Blz . . .
On Error GoTo TrataErro [ô]Caso ocorra um erro ele irá para a rotina TrataErro
Set banco = OpenDatabase(App.Path & [Ô]\db5.mdb[Ô]) [ô]Abro o banco de dados
Set tborc = banco.OpenRecordset([Ô]PedOrc[Ô], dbOpenTable, dbDenyWrite) [ô]Abro a tabela como dbDenyWrite - ou seja o banco de dados ficará disponÃvel apenas para essa pessoa .
TrataErro: [ô]Caso de erro ( outra pessoa tenta abrir a base de dados virá para essa rotina )
If MsgBox([Ô]Não é possÃvel efetuar esta operação no momento. Aguardar?[Ô], vbYesNo + vbQuestion, [Ô]Orçamentos e Pedidos[Ô]) = vbYes Then [ô]Faço um pergunta se deseja esperar a liberação da base de dados
Resume [ô]Se quiser esperar, mando o Resume para que o programa continue da linha que deu o erro
Else [ô]Senão
Unload Me [ô]Fecho a tela
End If
. . .
Essa dica é do Marcelo-Treze.
Gravei ela, pois achei interessante a imposição em que um sistema em rede impõe necessidades, em que o programador
tem que se virar, pra que não digam que seu sistema não é bem bolado e todos fiquem felizes.
Se funfar, todos os créditos são do mano [txt-color=#e80000][txt-size=2]Marcelo-Treze[/txt-size][/txt-color], Blz . . .
On Error GoTo TrataErro [ô]Caso ocorra um erro ele irá para a rotina TrataErro
Set banco = OpenDatabase(App.Path & [Ô]\db5.mdb[Ô]) [ô]Abro o banco de dados
Set tborc = banco.OpenRecordset([Ô]PedOrc[Ô], dbOpenTable, dbDenyWrite) [ô]Abro a tabela como dbDenyWrite - ou seja o banco de dados ficará disponÃvel apenas para essa pessoa .
TrataErro: [ô]Caso de erro ( outra pessoa tenta abrir a base de dados virá para essa rotina )
If MsgBox([Ô]Não é possÃvel efetuar esta operação no momento. Aguardar?[Ô], vbYesNo + vbQuestion, [Ô]Orçamentos e Pedidos[Ô]) = vbYes Then [ô]Faço um pergunta se deseja esperar a liberação da base de dados
Resume [ô]Se quiser esperar, mando o Resume para que o programa continue da linha que deu o erro
Else [ô]Senão
Unload Me [ô]Fecho a tela
End If
. . .
O problema no exemplo do Marcelo-treze é que se o usuário ficar namorando o form por muito tempo, ninguém mais vai acessar esta tabela pra fazer alteração até que ele faça a alteração e libere a tabela.
Uma outra forma seria montar um controle de alterar na tabela somente os campos que sofreram alteração, aà preservaria alterações feitas em outros campos por outro operador.
Outra forma também seria ao consultar, atualizar imediatamente um campo de status no cadastro tipo=1 em manutenção após alterar, atualizar o status para 0=liberado. Assim o próximo que acessar o sistema checaria o status, se for 1, dá a msg dizendo que está em uso e pedindo pra aguardar. neste caso, travaria só o registro e não a tabela inteira.
Bem, pode ter outras sugestões que com certeza virão dos amigos internaltas.
Abraços.
Uma outra forma seria montar um controle de alterar na tabela somente os campos que sofreram alteração, aà preservaria alterações feitas em outros campos por outro operador.
Outra forma também seria ao consultar, atualizar imediatamente um campo de status no cadastro tipo=1 em manutenção após alterar, atualizar o status para 0=liberado. Assim o próximo que acessar o sistema checaria o status, se for 1, dá a msg dizendo que está em uso e pedindo pra aguardar. neste caso, travaria só o registro e não a tabela inteira.
Bem, pode ter outras sugestões que com certeza virão dos amigos internaltas.
Abraços.
JCarlos tem Tem razão, esta é uma discução que vem se arrastando, de ante mão gostaria de agradecer o colega MICROSCHEME, pelos créditos, mas este código também não é meu, é resultado de uma pesquisa na net, e lógico é um código de longa data, realmente existe o problema de uma pessoa bloquear o registro por um longo tempo, isto inclusive é explicado no tópico em que abordo sobre abrir como DenyWrite.
Voltando ao que o colega JCARLOS disse, a solução postada por ele foi a melhor que encontrei para evitar problemas.
então boa sorte.
Voltando ao que o colega JCARLOS disse, a solução postada por ele foi a melhor que encontrei para evitar problemas.
*o Melhor deste forum é isso, usuários buscando melhor forma desenvolvimentoentão boa sorte.
Usava este mesmo esquema que o colega JCARLOS comenteu, mas tive uns problemas de micro travar, reinicar e o registro ficar marcado como [Ô]sendo editado[Ô] ai tinha que orientar o cliente a roda uma rotina para [Ô]desbloquear[Ô] o registro, ai criei a minha propria solução.
A solução foi criar a mesma logica que o Access usa. Quando vc abre um arquivo mdb o Access cria outro arquivo com extensao ldb, isso indica que ele esta aberto.
Entao faço o seguinte, qdo um registro vai ser editado, crio um arquivo txt renomeado para lck, exemplo: clie00001.lck e mantenho esse txt aberto enquanto o registro estiver sendo editado. Se outro usuario tentar editar aquele registro, primeiro verifico se existe o txt e tento exclui-lo, se estiver aberto ele retornara um erro pois nao é possÃvel excluir um arquivo aberto, e desta forma sei que esta sendo editado e o usuario recebe uma mensagem para tentar mais tarde
Uso isso a anos em sistemas com 20, 30 maquinas e numca deu problema.
A solução foi criar a mesma logica que o Access usa. Quando vc abre um arquivo mdb o Access cria outro arquivo com extensao ldb, isso indica que ele esta aberto.
Entao faço o seguinte, qdo um registro vai ser editado, crio um arquivo txt renomeado para lck, exemplo: clie00001.lck e mantenho esse txt aberto enquanto o registro estiver sendo editado. Se outro usuario tentar editar aquele registro, primeiro verifico se existe o txt e tento exclui-lo, se estiver aberto ele retornara um erro pois nao é possÃvel excluir um arquivo aberto, e desta forma sei que esta sendo editado e o usuario recebe uma mensagem para tentar mais tarde
Uso isso a anos em sistemas com 20, 30 maquinas e numca deu problema.
Quanto ao problema de um usuário tirar um cochilo com o aplicativo aberto dê uma olhada neste link:
http://www.vbmania.com.br/pages/index.php?varModulo=Forum&varMethod=abrir&varID=339256&varWorld=
Nele eu passei prum camarada um pequeno aplicativo que faz o logout do usuário caso a inatividade alcance um tempo pré determinado
é só baixar e verificar se por acaso não te ajuda quanto a inatividade com os bancos abertos
. . .
fala ai galera!
estou um pouco sumido, mas achei interessante fazer um comentário neste post!
verificar se 2 pessoas estão mexendo ao mesmo tempo no mesmo registro acho um pouco de preciosismo porque:
se 1 usuário altera o cadastro, e depois de alterado outro usuário abre o mesmo cadastro vê que foi alterado ele pode mudar de novo, e o as alterações do primeiro usuário tbm vão se perder!
isso entra mais na polÃtica da empresa mesmo:
eu acho que não precisa fazer um controle desse para impedir que 2 usuários ao mesmo tempo altere um cadastro de cliente, mas este tipo de alteração sempre usar transação no banco de dados! SEMPRE!
vamos imaginar outro caso
Tenho 2 caixas que ao mesmo tempo estão vendendo o produto A, os 2 caixa enxergavam que o produto A tem 5 unidade no estoque, o primeiro caixa esta vendendo a qta 1 de A e o caixa dois esta vendendo a qtd 2 de A, temos duas formas de atualizar o estoque:
caixa A
qtdAntigo = 5
qtdVendido = 1
update tabela set estoque = qtdAntigo - qtdVendido
desta forma provavelmente de problemas se os 2 caixa estiverem fazendo a venda do mesmo produto
mas se atualiza assim
update tabela set estoque = estoque - qtdVendido
ja n tera mais problema
tudo isso com controle de transação em!
mas para resolver o problema de 2 pessoas estarem alterando o mesmo cadastro de cliente, o ideal e mesmo fazer um log com as alterações do cadastro, mostrando o que foi mudado, quando, por quem foi alterado, valor anterior e valor atualizado.
esse sim seria o controle perfeito, mas eu sei que fazer log é um saco, e muitas vezes não é feito porque imaginam que não terá muitos benefÃcios, mas quando o software se torna grande e as informações que estão nes se tornam importantes este tipo de informação de log é fundamental.
imaginem em uma empresa que tenha um cliente que faça todo mes uma compra de 2 milhões de reais!, ai chega um cara e altera o endereço de entrega deste cliente. ai os produtos não são entregues no endereço correto e a empresa corre o risco de perder este cliente vocês não acham que seja fundamental ter um log para saber quem foi o Zé que alterou o cadastro deste cliente, e qual era o endereço anterior?
valew gente
estou um pouco sumido, mas achei interessante fazer um comentário neste post!
verificar se 2 pessoas estão mexendo ao mesmo tempo no mesmo registro acho um pouco de preciosismo porque:
se 1 usuário altera o cadastro, e depois de alterado outro usuário abre o mesmo cadastro vê que foi alterado ele pode mudar de novo, e o as alterações do primeiro usuário tbm vão se perder!
isso entra mais na polÃtica da empresa mesmo:
eu acho que não precisa fazer um controle desse para impedir que 2 usuários ao mesmo tempo altere um cadastro de cliente, mas este tipo de alteração sempre usar transação no banco de dados! SEMPRE!
vamos imaginar outro caso
Tenho 2 caixas que ao mesmo tempo estão vendendo o produto A, os 2 caixa enxergavam que o produto A tem 5 unidade no estoque, o primeiro caixa esta vendendo a qta 1 de A e o caixa dois esta vendendo a qtd 2 de A, temos duas formas de atualizar o estoque:
caixa A
qtdAntigo = 5
qtdVendido = 1
update tabela set estoque = qtdAntigo - qtdVendido
desta forma provavelmente de problemas se os 2 caixa estiverem fazendo a venda do mesmo produto
mas se atualiza assim
update tabela set estoque = estoque - qtdVendido
ja n tera mais problema
tudo isso com controle de transação em!
mas para resolver o problema de 2 pessoas estarem alterando o mesmo cadastro de cliente, o ideal e mesmo fazer um log com as alterações do cadastro, mostrando o que foi mudado, quando, por quem foi alterado, valor anterior e valor atualizado.
esse sim seria o controle perfeito, mas eu sei que fazer log é um saco, e muitas vezes não é feito porque imaginam que não terá muitos benefÃcios, mas quando o software se torna grande e as informações que estão nes se tornam importantes este tipo de informação de log é fundamental.
imaginem em uma empresa que tenha um cliente que faça todo mes uma compra de 2 milhões de reais!, ai chega um cara e altera o endereço de entrega deste cliente. ai os produtos não são entregues no endereço correto e a empresa corre o risco de perder este cliente vocês não acham que seja fundamental ter um log para saber quem foi o Zé que alterou o cadastro deste cliente, e qual era o endereço anterior?
valew gente
Bom pessoal, boa tarde a todos, o que eu desejo fazer é o seguinte: Esse é um modulo de telemarketing.. quanto o usuário X chamar um cadastro para sua tela.. não deixar o usuário Y Usar esse registro.. ou seja, está reservado ao usuário X...
Tópico encerrado , respostas não são mais permitidas