Sobre transações

|- comandos do tipo SELECT abrem transações no Firebird?

mesmo só a seleção de registros (SELECT) precisa estar no contexto de uma transação no Firebird


|Supomos que eu tenha um sistema com um formulário de consulta.
|Quando o formulário é aberto, executa um SELECT em uma Query que
|traz registros do banco segundo alguns critérios. Pergunto: no momento
|que a instrução Open da Query é executada, uma transação associada à
|tabela da Query é aberta no Firebird?

quem faz isso automático (ou não) é o componente de acesso (tipo o IBX) e não o Firebird. O Firebird precisa que vc abra uma transação *antes* de executar qualquer comando nos dados, mesmo um select.

|Perguntando de outra maneira: existiria risco de deadlock devido à
|suposta transação aberta pela instrução SELECT nessa consulta?

NÃO. Simplesmente abrir uma transação não bloqueia um registro. Q q bloqueia o registro é uma alteração no mesmo (update) ou lock explícito (select for update)


|em um DataSet, a transação é aberta no momento da execução dos
|métodos Insert/Update, ou só no momento da gravação dos dados (
|Post )?

Depende completamente do DataSet. Isso é algo dos componentes de acesso e não do banco de dados.

Para as suas outras questões, sem saber quais componentes usa e como os configura, é impossível responder.


T+

Olá
Antes de mais nada, obrigado pelas respostas, já foram de grande ajuda.
A suíte de componentes que estou usando atualmente para o Firebird é o IBX. Sei que não é o adequado, devido ao risco de futura incompatibilidade, mas eu uso porque é free.
O nível de isolamento do objeto IBTransaction é Read Commited, e os DataSets em questão são IBDataSets.
Obrigado, abraços

|Quando o método Insert ( ou Update ) é executado para manipulação de
|registros, a transação é aberta?

no caso do IBDataSet a transação já está aberta desde que vc o abriu (open).


|Se o primeiro caso for verdadeiro, seria melhor utilizar componentes
|normais ( TEdits ) combinados com instruções INSERT/UPDATE que
|seriam executadas somente após todos os dados serem digitados?

se é melhor depende muito da aplicação. é melhor em termos de manter transações curtas, mas nem toda aplicação precisa se preocupar com isso -- dai tem q avaliar o custo/benefício.


T+

OK, obrigado! :D
Eu pensava o seguinte:
Se a máquina A abrisse uma transação pra uma tabela ( um SELECT por exemplo ), e depois a máquina B abrisse outra transação pra mesma tabela e tentasse commitar ( com a primeira transação pendente ), daria deadlock.
Mas isso só aconteceria se ambas as máquinas abrissem o mesmo registro para edição, correto?
Abraços

|Mas isso só aconteceria se ambas as máquinas abrissem o mesmo
|registro para edição, correto?

isso. se a primeira alterar o registro x e antes de ´comitar´ a segunda tentar alterar o mesmo registro.


T+

Beleza. Foi tudo muito esclarecedor.
Abraços

como fico sabendo, na aplicação, se um registro já está sendo editado por um outro usuário?

|como fico sabendo, na aplicação, se um registro já está sendo editado
|por um outro usuário?

ao tentar alterar o registro, vc receberá um erro informando q o registro está bloqueado -- mas sua transação tem q estar configurada como ´NO WAIT´ -- do contrário, em vez do erro sua aplicação apenas ficará ´parada´ aguardando a liberação do registro


T+

Quando se faz a instrução Select no Firebird com IBX se inicia uma transação, tudo bem. Ma antes de se fechar a tabela é necessário fazer o commit ou rolback?

|Ma antes de se fechar a tabela é necessário fazer o commit ou rolback?

não.


T+