Gestión de transacciones

[MartinS]

Si Birmain ese codigo lo puse como mas o menos queria hacerlo. Como dije primero se que existe una transaccion abierta y no encontraba bien cuando arrancaba.-

Y para Casimiro: Efectivamente solo uso un IbTransaction asociado al Database. Ahora bien, Por inexperiencia pregunto: ¿ No es problematico que se inicie la transaccion al iniciar el programa e ir haciendo los commit o rollback de acuerdo a las situaciones que se presenten?. Es decir, cuando arranca el programa me estoy despreocupando de la transaccion la cual cierra (Active = False) recien al cerrar el programa.-

[Casimiro Noteví]

Empezado por MartinS

Y para Casimiro: Efectivamente solo uso un IbTransaction asociado al Database. Ahora bien, Por inexperiencia pregunto: ¿ No es problematico que se inicie la transaccion al iniciar el programa e ir haciendo los commit o rollback de acuerdo a las situaciones que se presenten?. Es decir, cuando arranca el programa me estoy despreocupando de la transaccion la cual cierra (Active = False) recien al cerrar el programa.-

Pues no sé si será problemático, pero es lo que llevo haciendo desde hace 14 años y no he tenido ningún problema hasta ahora.

[MartinS]

Empezado por Casimiro Notevi

Pues no sé si será problemático, pero es lo que llevo haciendo desde hace 14 años y no he tenido ningún problema hasta ahora.

Justo lo que necesitaba escuchar!!. Va.. leer
Es así como he venido trabajando pero hay momentos en los cuales te replanteas un poco las cosas que venís implementando.

Gracias compañero. Saludos.-

[[birmain]]

Veo que hay muchos enfoques a la hora de utilizar la transacciones. Todo depende en que proceso se encuentre uno y que es lo que ese proceso va hacer. En algunos casos podría ser necesario hacer actualizaciones en caché, y para salvar los resultados o cancelarlos aplicar o cancelar la actualización en el seno de una transacción explícita que englobe todo un proceso lógico que deba conservar una integridad lógica. En este caso es adecuado definir una transacción para este proceso, comenzarla con StartTransancion y finalizarla con un commit o rollback.

En la mayoría de los casos, cuando se trata de una edición de datos en un formulario, mas o menos compleja, a mi juicio, lo idóneo es definir una transacción asociada todas las consultas y procedimientos almacenados que intervengan en los procesos de edición, y en el evento de cierre del formulario hacer un commit o rollback de esta transacción, que a su vez cerrará todos los dataset que intervienen en este.

Podría haber, y de hecho hay mas casuísticas. Pero estas dos son las más genéricas. En principio y en resumén una sola conexión por aplicación en un módulo "auto-create" al comienzo de la aplicación con una transacción por defecto. En cada uno de los formularios, en el data modulo asociado a este, una transacción que apunte a la conexión común en todos los datasets, y que termine al cerrar cada uno de los formularios, y que comienze al abrirlos (Haciendo open a cada uno de los datasets).

Me llamó poderosamente la atención la aplicación de muestra de la base de datos emplooye.fdb, donde únicamnete utilizaba una transacción vinculada con la conexión original, para toda la aplicación.

[MartinS]

Me llamó poderosamente la atención la aplicación de muestra de la base de datos emplooye.fdb, donde únicamnete utilizaba una transacción vinculada con la conexión original, para toda la aplicación.

Efectivamente y me paso algo similar cuando observe el ejemplo de IBX Mastapp.
Saludos y gracias.-