Cuantas transacciones

[rochi]

Hola, como he dicho en otros posts de Delphi, soy nueva en esto de Delphi + Firebird 1.5.1, utilizando componentes IBX.

Tengo una aplicación, con las a/b/m usando IBDataSets para tablas no maestro, ClientDataSEts, para actualizar maestro-detalles, y IBQuery para realizar búsquedas. El asunto es que por ahora uso una misma txn para todo.
Dependiendo que parte de la bd se está actualizando, es quien es usa la txn para sus procesos correspondientes.

No he tenido inconvenientes, pero la intuición femenina me dice que no es lo mas aconsejable ....además leí en el Help de IBX que viene con Delphi que c/query debe tener su propia tnx, aun no he encontrado explicaciones para ello.
Y como no conozco el funcionamiento interno de las txns, estoy en ascuas

Se que la pregunta es un tanto general, pero ¿cual es el criterio para decidir entre una o mas tnx?.
Les agradezco las sugerencias o comentarios a esto.
Saludos, rochi

[Mick]

Cada transaccion define un conjunto de modificaciones sobre la base de datos que deben hacerse de forma atomica, eso significa que o se hacen todas o no se hace ninguna.
Esto permite mantener la coherencia en la base de datos aunque se produzca algun error en el medio de las transacciones, o algun conflicto con otro cliente/usuario.
Asi que la cuestion no es ni tener una unica transaccion para todo ni una transaccion por cada query, sino que cada proceso hay que estudiarlo y definir una o mas transacciones segun sea necesario:
Por ejemplo si tenemos un proceso de salida de articulos en el que realizamos lo siguiente:
1. Creamos un albaran de salida de articulos, guardando en una tabla de detalles la lista de articulos y cantidades que salen del almacen.
2. Actualizamos la tabla de stocks o de articulos restando las cantidades de cada articulo que han salido.

En este proceso de ejemplo vemos que si por algun problema, se realiza el punto 1 del proceso, pero el punto 2 da error (supongamos que se perdio la conexion de red entre medias) la base de datos quedara con informacion incoherente, tendremos un albaran que nos indica que ha salido determinado material pero si miramos el stock, en este nos constara que tenemos articulos de mas (porque no se ha podido restar las cantidades por el error anterior).

Luego para este proceso:
-Iniciamos una transaccion (Start)
-Realizamos el punto 1
-Realizamos el punto 2
-Si todo ha ido bien, confirmamos la transaccion (Commit).
-Si se produce algun error en alguno de los puntos: cancelamos (RollBack)

Al realizarse los dos procesos dentro de una misma transaccion si el punto 2 da error y no puede realizarse, hariamos un rollback de modo que la transaccion se anularia, lo que implica que todos los procesos realizados anteriormente desde que se inicio la transaccion son cancelados, es como si nunca se hubiese realizado el punto 1, de modo que nunca tendremos incoherencias entre informacion relacionada que se encuentre guardada en distintas tablas de la base de datos.

En este ejemplo vemos que tendriamos una unica transaccion para el proceso,
pero ejecutariamos varias queries de actualizacion sobre la base de datos, todas estas queries tienen que utilizar esa misma transaccion.

Lo que si se puede hacer para ahorrar en el uso de componentes TIbTransaction es utilizar un unico componente TIbTransaction con un nivel de aislamiento: ReadCommited, para todos los procesos y queries de consulta del programa. Es decir operaciones que no impliquen modificaciones en la base de datos: listados, consultas , etc, todas podrian utilizar el mismo componente.

Saludos

[StartKill]

Wnas foro

Esta pregunta me la plantee hace un buen tiempo: "que es recommendable?", una transaccion por ibquery o una transaaccion por todas... ibquery, ibsql...

La poca expereciencia en el mundo de la programacion de delphi con interbase y debo suponer con otros lenguajes y motores de base de datos cliente servidor me ha enseñado:Que el uso de las transacciones es a buen criterio del programador (segun la necesidad), te doy un ejemplo y saca una conclusion de ello.

Debo suponer que conoces ya el uso de los componentes ibx y al menos algunos conceptos en la programacion de ellos...

Supongamos que tenemos dos tablas: una es la Clientes y la otra la de Abonos, lo justo y normal es que exista un registro en Clientes y cero, uno o varios registros en la tabla abonos por cada cliente.

Código PHP:

tabla Clientes
   codclie     Cargo     Abono
   ====================
   00001     100.23    33.00
   00002     123.63    10.00
   00003       78.68    32.00
   00004       74.00    22.00

tabla Abonos
   codcli    recibo        Abono   fecha
   ===============================
   00001     FG001252   10.00   12/12/2004
   00001     FG001253   11.00   13/12/2004
   00001     FG001254   12.00   15/12/2004

   00002     FG001255   10.00   12/12/2004

   00003     FG001256   11.00   12/12/2004
   00003     FG001257   10.00   14/12/2004
   00003     FG001258   11.00   16/12/2004

   00004     FG001259   12.00   18/12/2004
   00004     FG001260   10.00   19/12/2004 


Si observas en la tabla cliente: la columna abono es la suma de la columna abono de la tabla Abonos ;-)

Imaginemos la actualizacion de estas tablas....

Código PHP:

1.- dos ibquery.
2.- una transaccion  que sera compartida para los dos ibquerys.
3.- inicializo la transaccion.
4.- inserto un registro con nuevos datos en abonos.
5.- actualizo el campo abono de la tabla clientes sumando el monto 
     existente mas el nuevo abono de la tabla abonos.
6.- aplico la transaccion. 


Con este metodo de una sola transaccion me aseguro que se confirme los datos tanto para la tabla clientes y la tabla abonos.... si sale algo mal en la actualizacion de la tablas la transaccion se deshace ;-) y las dos tablas quedan como estaban.

Si hubiera sido dos transsaciones una para cada tabla????
Imaginate que la primera transsacion se confirme osea la de clientes y por alguna razon del destino en la segunda tabla de abonos ocurre algun error: (error de unique, clave foranea...cualquier error)...ah??, como quedan las tablas??... respuesta: solo la tabla clientes confirmada la transaccion y la segunda "rollback", transaccion deshecha. y tus tablas no quedarian consistentes (la suma de abono en la tabla abonos no reflejaria lo que indica en abono de la tabla clientes).

Entoces en este caso se sugiere usar una sola transaccion... ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion----tienes razon, pero esto es un ejemplo que se me ocurrio para explicar el uso de las trasacciones

Bueno, no soy profesor, espero haberme hecho entender: eso depende de tu necesidad, una de las ideas del uso de las transaciones es la consistencia extra de tus datos...(o todo o nada)

Your friend,

StartKill
Lima-Perú

[rochi]

Muy claro los 2 ejemplos. Similares en el concepto.
Me quedó claro que las txns las debo usar con el criterio de mantener la coherencia de los datos en un proceso. El corolario primario de todo esto, es que la cantidad de txns dependerá de cuantas cosas (queries,ibdataset,etc) estén involucradas y deba agrupar para realizar un proceso con éxito.

Pero he aqui mi nueva duda:

Entoces en este caso se sugiere usar una sola transaccion... ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion----tienes razon, pero esto es un ejemplo que se me ocurrio para explicar el uso de las trasacciones

¿podrías aclararme esta opción por favor? Te referís a una stored procedure?! o a una actividad desencadenada desde un trigger?. Y lo otro, si están en distintas txns, ¿no corro el mismo riesgo?, que ante un error al aplicarse un commit una de ellas quede sin los cambios mientras se aplicaron en la otra?.
Tal vez no te entendí...y por eso mis preguntas,..te agradezco la aclaración

Muchas gracias, la verdad muy claros sus ejemplos
Saludos

rochi

[sur-se]

Todas las querys, procedimientos almacenados y triggers que se disparen están bajo la transacción que esté asociada al componente, es decir, los triggers van asociados a la transacción del componente que provocó su disparo.
Por otra parte, quiero hacer una pequeña aportación a todo esto de las transacciones. Normalmente, para las aplicaciones SDI el número de transacciones a utilizar será menor que en aplicaciones MDI (en las que podríamos tener varias ventanas y procesos simultáneos), simplemente por el hecho de que sólo podemos tener una ventana activa en cada momento (ignorando a groso modo los posibles threads).
De todas formas, es evidente que las transacciones van a depender de los procesos que realices y de como programes. Lo que si hay que tener claro es que si una transacción modifica datos, que termine lo antes posible (es decir que no requiera la interacción del usuario).
Salu2.

[rochi]

Empezado por sur-se

Todas las querys, procedimientos almacenados y triggers que se disparen están bajo la transacción que esté asociada al componente, es decir, los triggers van asociados a la transacción del componente que provocó su disparo.

entiendo, lo que decís, me aclara las cosas.
Pero hace que entienda menos la frase de StartKill, no digo por el, por mis limitaciones...
"ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion" que se refiere a la actualización de 2 tablas que por algun motivo están relacionadas. Asumo que hay 2 txns diferentes...por eso preguntaba........y que aun no entiendo

Saludos, rochi

[StartKill]

Wnas foro,

j,j,j,j,j, tienes razon son parecidos las dos repuesta pero te aseguro que nadie copio del otro (lo digo por mi), hoy reviso el foro y me di cuenta que my friend Mick me gano en la respuesta (digita ud. mas rapido que yo).

Hola Rochi, te preguntas por el comentario que hice:

original de StartKill

Entoces en este caso se sugiere usar una sola transaccion... ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion----tienes razon, pero esto es un ejemplo que se me ocurrio para explicar el uso de las trasacciones

y te preguntas??

Original de rochi

¿podrías aclararme esta opción por favor? Te referís a una stored procedure?! o a una actividad desencadenada desde un trigger?

A si es hablo de procedures en el motor de base de datos "stored procedure", me explico: Como sabras dentro de un stored procedure puedes manejar varias tablas sin necedidad de tener uno, dos o mas ibquerys. A decir que mejor lo hagas con procedure me referia: Mejorar la velocidad de proceso y evitar utilizar ibquery ;-)

Ahora, esta demas decir que si tienes un procedure que maneje "n" tablas... solamente necesitaras una transaccion--->para el stored procedure y ningun ibquery-innecesario,.... claro que la transaccion que apunta a dicho stored procedure podra hacerlo a otros componentes "Ibquerys, storedProcedure..."(como tu dices: para mantener la coherencia de datos).

Bueno, me despido y gracias a nuestros Moderadores, Amigos... que hacen posible compartir nuestras experiencias y que podamos consultar dudas que nos caen dia a dia.

Un Abrazo y una Feliz Navidad y Prospero año Nuevo 2005.

Your friend,

StartKill
Lima-Perú.

Es bueno probar y experimentar para tener experiencia, pero es mas agradable que me enseñen para evitar perder tiempo y equivocarme tontamente.

[rochi]

Gracias por la aclaración Startkill , cada cosa que agregan me aclara esto un poco más, y por las repeticiones.....no hay problema, mejor si coinciden, refuerzan la idea. Imaginate si fueran opuestas

Por si no nos 'vemos' antes, o si no vemos igual, a todos Felices Fiestas y un buen 2005.

Saludos

rochi