[[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.