Cuantas transacciones

[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