34 replies to this topic

[enecumene]

[enecumene]

Se me acaba ocurrir otra causa, es posible que cuando estoy haciendo algun cambio, update en vivo desde el IBExpert y al hacer commit podría afectar todas las transacciones activas?.

[santiago14]

Se me acaba ocurrir otra causa, es posible que cuando estoy haciendo algun cambio, update en vivo desde el IBExpert y al hacer commit podría afectar todas las transacciones activas?.

 

Mmmm, no. Yo hago lo mismo y no afecto las transacciones del Sistema.

Debe ser otra cosa dentro del código.

[enecumene]

Mmmm, no. Yo hago lo mismo y no afecto las transacciones del Sistema.

Debe ser otra cosa dentro del código.

 

Bien, se me acaba de ocurrir otra posible causa, como yo ando creando los datasets en memoria y lo endoso dentro de un try..finally al ocurrir una excepción, llegaría a liberarse dicho dataset?, es posible si no se liberara se quedara en el limbo y que fuese sustituido por otra transacción?, digo, sino, sigo insistiendo que podrían ser actividades paranormales.
 

[santiago14]

Bien, se me acaba de ocurrir otra posible causa, como yo ando creando los datasets en memoria y lo endoso dentro de un try..finally al ocurrir una excepción, llegaría a liberarse dicho dataset?, es posible si no se liberara se quedara en el limbo y que fuese sustituido por otra transacción?, digo, sino, sigo insistiendo que podrían ser actividades paranormales.
 

 

Ajá.

Si no es mucho lío, puedes crear un TFDQuery arrastrando un componente a tu Form. Y probar que pasa ahí. Lo asocias a una transacción y a un Connection.

Te mando una foto para que veas mi DataModule con todos esos componentes FireDAC. 

 

Santiago.

Attached Files

•  FotoXE5.png   183.06KB   4 downloads

[enecumene]

Me costará poner los Datasets en Diseño, lo he estado haciendo así para evitar ver tantos datasets en un Datamodule, me vuelvo bizco   

[santiago14]

Me costará poner los Datasets en Diseño, lo he estado haciendo así para evitar ver tantos datasets en un Datamodule, me vuelvo bizco 

 

Jajajaj, sí.

Pero bueno, en una de esas la solución está por ese lado.

[FerCastro]

[OFF TOPIC]

 

 

 

Saludos

 

He leído todo el hilo y al final me he quedado mudo, pues si existe intervención de entes de ultratumba, la verdad hasta allá no llego.

 

YO trabajo con Oracle y con MySQL y en ambas utilizo un objeto transacción para el manejo de las mismas, y hasta ahora cero problemas. Creo que deberías sumergir tu equipo en agua maldita, o de plano hacer un sacrificio de una doncella, si la encuentras.

 

Saludos!!

[Agustin Ortu]

Bien, se me acaba de ocurrir otra posible causa, como yo ando creando los datasets en memoria y lo endoso dentro de un try..finally al ocurrir una excepción, llegaría a liberarse dicho dataset?, es posible si no se liberara se quedara en el limbo y que fuese sustituido por otra transacción?, digo, sino, sigo insistiendo que podrían ser actividades paranormales.
 

 

Un poco tarde, pero en un try-finally, el finally se ejecuta incluso aunque ocurran excepciones. Lo unico que puede "abortarte" un finally es que ocurra una excepcion dentro del propio finally, en ese caso el finally no se ejecuta completamente

[asapltda]

hola enecumene,

Tengo el mismo problema cuuando migre un sistema a firedac, quisiera saber si encontro la solucion al problema gracias

[Agustin Ortu]

Simplemente usa los métodos de la clase Connection y no vas a tener problema

[asapltda]

Uso de transacciones con Firedac y Firebird

 

Enncontre una posible causa problema:

Firebird puede manejar transacciones anidadas. cuando se inicia el programa usando coneccion con firedac por omision es autocommit. 

Normalmente colocamos :

1. transaccion.StartTransaction;
2. try
3. execute procedurex
4. commit
5. except
6. rollback
7. end
8. la transaccion ya existe lo que quiere decir es que si preguntamos
9. if DB_Firedac.InTransaction  =  false  then

       DB_Firedac.StartTransaction;

    

   con esa intruccion evitamos anidar las transacciones

    

   pero de otro forma nos tocaria dar 2 veces commit

   para que los cambios sean visibles a otros usuarios

    

    

una forma de evitar que sucedandos transacciones seria:

DB_Firedac.TxOptions.EnableNested := False ;  

esto nos generaria un error en ejecucion si tratamos de iniciar una  transaccion anidada

[enecumene]

Ya con hacer uso del TFDConnection te evitas todo eso, así al final fue como lo hice:

delphi

Connection.StartTransaction;
try
  //Funciones, procedimientos etc:
  Connection.Commit;
except
  Connection.RollBack;
end;

[Agustin Ortu]

Para el caso de motores como Firebird que soportan anidamiento de transacciones, segun la documentacion, es correcto el uso del componente dedicado. Aunque como nunca he trabajado con este concepto no puedo aportar mucho mas

 

De todos modos, vuelvo a recalcar lo que ya hemos dicho y es justamente lo que comenta Fernando en el ultimo post: ese pedazo de codigo para manejar transacciones en Delphi con <practicamente cualquier biblioteca de acceso a datos> deberia ser un patron con nombre y apellido.

[Delphius]

El compañero asapltda sin querer reportó el hilo en lugar de responder. Este nos comenta:

 

Hola migre de SQLDIRECT a Firedac y he tenidos muchos dolores de cabeza porque EN SQLDIRECT UNO ININICA LA TRANSACCION Y LA TERMINA EXPLICITAMENTE

En firedac revise los parametros de autocommit, aotostart, autostop, disconectaction para manejo de transacciones, porque la omision es autocomit y la trasaccion esta activa, si actualiza mas de una tabla con autocommit no reversa las primeras tablas con rollback
esa es mi experiencia

 

 

Saludos,