ClientDataSet: como gerenciar acesso concorrente?
13/01/2006
0
mas quando usamos o ClientDataSet, como vai ser feito este controle já que ele carrega os dados na memória e fecha a conexão?
Raserafim
Posts
13/01/2006
Bruno Belchior
14/01/2006
Raserafim
se q não pode ser assim pois este componente é utilizado justamente para aplicações multi-camadas, mas não consegui entender...
15/01/2006
Vinicius2k
Creio que o que vc deseja fazer chama-se ´Travamento pessimista´. Uma prática muito comum, porém, na maioria das vezes, desnecessária se a questão for analisada com cuidado.
Quando se utiliza bancos de dados Desktop como Paradox, Access, dBase, etc, travar o registro é mais do que uma opção, é uma necessidade, porém, com SGBDs é, quase sempre, desnecessário.
A midas não é capaz de fazer isto. A forma de fazer vai variar de acordo com o SGBD. No Firebird, por exemplo, você precisa executar uma query com a instrução ´FOR UPDATE´ e/ou ´WITH LOCK´:
/* para uma query que retorna múltiplos registros */ select <CAMPOS> from <TABELA> where <CAMPO> = :parametro for update with lock /* para uma query que retorna apenas um registro */ select <CAMPOS> from <TABELA> where <CAMPO> = :parametro with lock
Nesta execução o(s) registro(s) é/são travado(s) para outros usuários até que a transação que efetou o LOCK seja fechada (commit ou rollback).
Antes de seguir o caminho do travamento pessimista, eu sugiro a leitura deste artigo que, na forma conceitual, é valido para qualquer SGBD, caso o que vc esteja utilizando não seja o FB: http://www.comunidade-firebird.org/cflp/downloads/CFLP_T032.PDF
T+
15/01/2006
Raserafim
então o q aconteceria na seguinte situação:
se eu não me preocupasse com nada disso. e em uma máquina cliente o camarada abrisse o cadastro de clientes em um determinado registro. e em outra máquina abrisse o mesmo cadastro de clientes com o mesmo registro. a primeira máquina alterasse a cidade do cliente, e na segunda alterasse o bairro do cliente. o q aconteceria?
15/01/2006
Marcello
No meu caso coloquei no provider a opção upWhereKeyOnly, então mesmo q altere o mesmo campo do cadastro o q vai valer é o último q foi gravado.
Acho muito díficil a situação de dois usuários atualizarem o cadastro do mesmo cliente, e caso isto ocorra o mais provavel é digitar os mesmos dados - endereço, fone, etc.
15/01/2006
Vinicius2k
Depende da configuração do TDataSetProvider. Como o colega Marcello citou com a propriedade ´UpdateMode´ do Provider você pode controlar como ele irá se comportar face a esta situação.
Com ´upWhereAll´ a instrução SQL de UPDATE montada pelo provider irá incluir na cláusula WHERE todos os campos com todos os valores que ele possuia originalmente, consequentemente, só será feita alguma alteração se nenhum dos campos tiverem sido alterados por outro usuário. Com isso a alteração feita pelo primeiro usuário prevalecerá e no evento OnReconcileError do TClientDataSet você terá o erro ´Record changed by another user´, após a tentativa de aplicar as alterações.
Com ´upWhereKeyOnly´ apenas a chave primária é incluída na cláusula WHERE da instrução de UPDATE. Se o primeiro usuário não alterar a chave primária (o que, normalmente, não é permitido por você), as alterações efetuadas pelo segundo usuário serão sobrepostas.
T+
Clique aqui para fazer login e interagir na Comunidade :)
