DUVIDA SIMPLES, MAS ESTOU ENRROLADO
Gostaria de abordar só uma questão que uso, mas sem muito saber...
Existem os bloqueios.... ao abrir o banco de dados;;;
Especificamente, quero saber qual o bloqueio que uso para uma aplicação que será utilizada em rede (x máquinas simultâneas, acessando o mesmo dado) utilizando o banco de dados Firebird....
adOpenDynamic, adLockOptimistic???
Existem os bloqueios.... ao abrir o banco de dados;;;
Especificamente, quero saber qual o bloqueio que uso para uma aplicação que será utilizada em rede (x máquinas simultâneas, acessando o mesmo dado) utilizando o banco de dados Firebird....
adOpenDynamic, adLockOptimistic???
Brother, particularmente não trabalho com travas. Modelo o sistema de forma que não tenha como duas pessoas editarem o mesmo registro pra evitar deadlocks. O Firebird trabalha com versões dos registros fortemente amarrado ao controle de transações e os seus tipos de isolamentos.
Por exemplo se duas pessoas (ou transações) acessarem o mesmo registro na mesma tabela uma delas pode alterar o registro e commitar a transação e a outra continua enxergando este mesmo registro sem as alterações submetidas pela outra transação, se esta for do tipo Concurrency, mas se essa transação tentar alterar este registro, mesmo após a primeira que o atualizou tenha sido encerrada, vc terá um deadlock pois enquanto a segunda transação estava ativa o registro foi alterado. Enfim, as transações tem que ser commitadas ou sofrer um rollback o quanto antes! No Firebird é furada esse negócio de abrir a conexão no load do sistema e encerrar no fechamento do sistema. é por isso que tem muita gente que alega que o sistema fica lento ao longo do dia e tem que ficar fazendo restore do BD, pois ele vai criando versões destes registros e os Ãndices ficam estufados. Abriu conexão, fez o que tinha que fazer, commit ou rollback e fim da conexão!
O isolamento ideal é o Read Commited, pois uma transação com este isolamento só retornará dados que já foram commitados por outra transação, ou se uma outra transação der um rollback, então vc não terá falsos positivos.
Acho que esse monte de informação deve está te confundindo, mas é assim mesmo. Sinceramente, ainda não uso o Firebird profissionalmente (apenas tenho estudado), e nem sei qual destas constantes da ADO iniciaria um dos tipos dos isolamentos dele na transação/conexão. Tenho que fazer um bacalhau pra testar isso. A princÃpio, se vc tem rotinas no seu sistema que possam acarretar em atualizações concorrentes, trate possÃveis deadlocks, e faça o código de forma que nenhuma transação fique pendurada num registro.
Só coloquei isso tudo pra te mostrar como é importante saber controlar as transações no Firebird, pois não é só problemas com deadlocks que vc pode ter que lidar. Flasos positivos em consultas também.
Mais informações aqui: http://www.firebase.com.br/fb/artigo.php?id=232
Por exemplo se duas pessoas (ou transações) acessarem o mesmo registro na mesma tabela uma delas pode alterar o registro e commitar a transação e a outra continua enxergando este mesmo registro sem as alterações submetidas pela outra transação, se esta for do tipo Concurrency, mas se essa transação tentar alterar este registro, mesmo após a primeira que o atualizou tenha sido encerrada, vc terá um deadlock pois enquanto a segunda transação estava ativa o registro foi alterado. Enfim, as transações tem que ser commitadas ou sofrer um rollback o quanto antes! No Firebird é furada esse negócio de abrir a conexão no load do sistema e encerrar no fechamento do sistema. é por isso que tem muita gente que alega que o sistema fica lento ao longo do dia e tem que ficar fazendo restore do BD, pois ele vai criando versões destes registros e os Ãndices ficam estufados. Abriu conexão, fez o que tinha que fazer, commit ou rollback e fim da conexão!
O isolamento ideal é o Read Commited, pois uma transação com este isolamento só retornará dados que já foram commitados por outra transação, ou se uma outra transação der um rollback, então vc não terá falsos positivos.
Acho que esse monte de informação deve está te confundindo, mas é assim mesmo. Sinceramente, ainda não uso o Firebird profissionalmente (apenas tenho estudado), e nem sei qual destas constantes da ADO iniciaria um dos tipos dos isolamentos dele na transação/conexão. Tenho que fazer um bacalhau pra testar isso. A princÃpio, se vc tem rotinas no seu sistema que possam acarretar em atualizações concorrentes, trate possÃveis deadlocks, e faça o código de forma que nenhuma transação fique pendurada num registro.
Só coloquei isso tudo pra te mostrar como é importante saber controlar as transações no Firebird, pois não é só problemas com deadlocks que vc pode ter que lidar. Flasos positivos em consultas também.
Mais informações aqui: http://www.firebase.com.br/fb/artigo.php?id=232
Adrianom,
Qualquer um dos bloqueios acaba sempre atrapalhando e causando uma certa lentidão no sistema multiusuário.
A solução para isso é como disse o LLAIA criar um mecanismo para que isso não aconteça, por exemplo:
Vc tem que ter uma base de dados server e uma cliente(no host), aà vc abre a conexão com o server, pede os dados despeja na BD do host e fecha a conexão com o server. Para evitar trazer um registo que esteja eventualmente a ser editado por alguém na rede, crie uma tabela onde cada produto por exemplo, que esteja a ser editado vá para lá e assim a requisição retorna uma msg dizendo que o produto Y está a ser editado por alguém.
OBS nessa tabela status, vão todos os registos que se encontrem em uso exclusivo. Uso este truque e tenho me dado bem
Os bloqueios as vezes [Ô]bloqueiam mesmo![Ô]
Qualquer um dos bloqueios acaba sempre atrapalhando e causando uma certa lentidão no sistema multiusuário.
A solução para isso é como disse o LLAIA criar um mecanismo para que isso não aconteça, por exemplo:
Vc tem que ter uma base de dados server e uma cliente(no host), aà vc abre a conexão com o server, pede os dados despeja na BD do host e fecha a conexão com o server. Para evitar trazer um registo que esteja eventualmente a ser editado por alguém na rede, crie uma tabela onde cada produto por exemplo, que esteja a ser editado vá para lá e assim a requisição retorna uma msg dizendo que o produto Y está a ser editado por alguém.
OBS nessa tabela status, vão todos os registos que se encontrem em uso exclusivo. Uso este truque e tenho me dado bem
Os bloqueios as vezes [Ô]bloqueiam mesmo![Ô]
Tópico encerrado , respostas não são mais permitidas