[firebase-br] RES: RES: RES: firebird na internet

[Gladiston Santana]

Taí uma coisa que a os componentes levam a culpa, mas notoriamente falta
entender o processo.

Se todos os componentes entendem o commit como fim de transação, a
transação não deveria ser fechada ?
Alguns componentes, é o caso do IBO tem uma propriedade de CommitActions
que permite Fechar/FetchAll/Invalidar cursores ou o refresh que é o que a
maioria quer, e isso facilita para o programador menos experiente. Mas não
precisa de uma propriedade assim se tomar a seguinte cautela.

O problema é que se atrelou tanto a edição como a consulta a mesma
transação.
Em minhas consultas com edição de dados, o componente de transação não é o
mesmo para o resto do programa, assim eu dou commit e fecho exatamente o
que deveria fechar, o dbgrid que está noutra transação permanece ativo.
Para facilitar essas operações eu "componetizo" quase tudo que vai ser
repetitivo, por exemplo, o "digitar o codigo do cliente" é um componente
tedit já grudado com um botão que se for usado abrirá uma janela para
pesquisa e edição de cadastro se necessário, porém esse componente traz sua
própria transação que não interferirá com o restante do programa quando
houver um commit dentro dele.

No Firebird, um commit tem que largar a transação. O commit retaining só
mesmo se ainda terá passos seguintes, manter a mesma transação por períodos
longos vai matar o banco.

Em 23 de março de 2013 12:31, Listas <listas em fasystem.com.br> escreveu:
>
> A IBX tem uma coisa muito ruim, ela simplesmente fecha os dados quando
> você dá um commit na transação, (por isso namoro o DBX). Alguns, por
> comodidade, usam CommitRetaining para solucionar o problema, mas daí cria
> outros, que são os famosos DEADLOCK nos registros utilizados.
>