Foros Club Delphi - ¿¿¿¿Quien realiza el Commit????

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Conexión con bases de datos (https://www.clubdelphi.com/foros/forumdisplay.php?f=2)

- - ¿¿¿¿Quien realiza el Commit???? (https://www.clubdelphi.com/foros/showthread.php?t=14996)

¿¿¿¿Quien realiza el Commit????

Uso FireBird 1.51, Delphi 7, IBX 7.08
Tengo esta duda:
Cuando llamo a un Procedimiento Almacenado en mi Aplicación(con un ibStoreProc) y dentro de este mismo hace algunas Inserciones de Registros, mi pregunta es...

¿Quien Acepta la Transacción Internamente FireBird ó los IBX para confirmar dichos registros Insertados?

Hago esta pregunta, porque cuando llamo el Proc. Almacenado mediante un IbStoreProc, no me actualizan los registros Insertados Hasta que me Salga de mi Aplicación y la vuelva a Abrir, aun así haberle puesto las instrucciones Refresh al ibDataset y un CommitRetaining ó Commit al ibtransaction después de haber llamado al mismo Proc. Almacenado.:confused:

Agradezco cualquier comentario.

Hola,

Cita:

Empezado por AGAG4

¿Quien Acepta la Transacción Internamente FireBird ó los IBX para confirmar dichos registros Insertados?

La gestión de transacciones es responsabilidad exclusiva del servidor Firebird. Otro asunto es que tú, desde tu aplicación cliente, ordenes al servidor que confirme (commit) o rechace (rollback) los cambios que has realizado en la transacción actual. ¿Cómo hacer esto? depende del método de acceso, y si este permite gestión ímplicita (tú te despreocupas de abrir y cerrar las transacciones) o, por contra, exige que explícitamente controles estas operaciones.

En el caso de IBX, admite ambas formas de trabajo. Aunque estoy muy "oxidado" con el uso de IBX, te recomendaría el control explícito (que tú abras y cierres las transacciones). Para ello tienes métodos (StartTransaction, Commit, CommitRetaining, Rollback, RollbackRetaining) en la clase TIBTransaction (te remito a la documentación).

Por cierto, el asunto del refresco de datos en otras transacciones (o clientes) concurrentes, suele estar relacionado con el nivel de aislamiento que tiene la transacción. Para poder ver cambios realizados en otras transacciones, el nivel de aislamiento debe ser read_commited

Saludos.

P.S. En estos foros ya se ha tratado varias veces este tema. El uso de las opciones de búsqueda te dará más de un hilo que trata el asunto.

Cita:

Empezado por kinobi

Hola,

La gestión de transacciones es responsabilidad exclusiva del servidor Firebird. Otro asunto es que tú, desde tu aplicación cliente, ordenes al servidor que confirme (commit) o rechace (rollback) los cambios que has realizado en la transacción actual. ¿Cómo hacer esto? depende del método de acceso, y si este permite gestión ímplicita (tú te despreocupas de abrir y cerrar las transacciones) o, por contra, exige que explícitamente controles estas operaciones.

En el caso de IBX, admite ambas formas de trabajo. Aunque estoy muy "oxidado" con el uso de IBX, te recomendaría el control explícito (que tú abras y cierres las transacciones). Para ello tienes métodos (StartTransaction, Commit, CommitRetaining, Rollback, RollbackRetaining) en la clase TIBTransaction (te remito a la documentación).

Por cierto, el asunto del refresco de datos en otras transacciones (o clientes) concurrentes, suele estar relacionado con el nivel de aislamiento que tiene la transacción. Para poder ver cambios realizados en otras transacciones, el nivel de aislamiento debe ser read_commited

Saludos.

P.S. En estos foros ya se ha tratado varias veces este tema. El uso de las opciones de búsqueda te dará más de un hilo que trata el asunto.

Muchas Gracias Sr. Kinobi por sus comentarios los tomare muy en cuenta, pues encontre una Solución no de mi agrado, lo que pasa es que cuando inicia mi aplicación, Se Conecta a la Base de Datos y despues Inicia la Transacción, pues bien, cuando yo llamo al Procedimiento Almacenado después Finalizo la Transacción y vuelvo a Abrir la Base de Datos y me Refresca las Inserciones del Proc. Almacenado, ahora, lo que me comenta sobre el Nivel de aislamiento, pues lo tengo como ReadCommited, en toda mi aplicación no me había pasado esto hasta que ahora me decido insertar registros por medio de un Proc. Almacenado, lo estaba haciendo por medio de las Propiedades que tiene un ibdataset InsertSQL, UpdateSQL, pero en fin, seguire haciendo pruebas. Que tenga buen día Sr. Kinobi.

Me pasa algo parecido,

Buenas tardes, estuve viendo tu mensaje y me pasa exactamente lo mismo, pero con los componente DBExpress, ademàs estoy tratando de agregar validación de modificacion de nombre, pero no se si mi procedimiento es el correcto.

Esto debido a lo siguiente
Cree una Exception saldo_check

Cree un triguer
CREATE TRIGGER "EJEMPLO2" FOR "EJETRIGUER"
ACTIVE BEFORE UPDATE POSITION 0
AS
BEGIN
IF ( OLD.NOMBRE <> NEW.NOMBRE) then
EXCEPTION SALDOS_CHECK;
END

Todo esto bien si lo hago directo en IBConsole, pero al estar en la aplicación, realizo la modificacion del registro y comito la transaccion, y aparantemente almacena los datos, pero al cerrar y volver a Abrir la aplicación en el renglon que modifique el nombre no se almaceno el cambio pero esto es correcto por el trigger, mas si modifico 2 renglones y en uno modifico el nombre y en otro no, en el que registro que modifique el nombre no se almacena la información y en el otro si, es detalle aqui es que las 2 modificaciones forman parte de la misma transaccion, por tal motivo se tendran que deshacer ambos cambios.

Si alguien sabe que se tiene que hacer para que el rollback se ejecute se lo agradeceria

Pues, yo tuve que Finalizar la Transacción y la Conexión a la Base de Datos y volver a restauranlas y asi me refresca los registros insertados por el Procedimiento Almacenado. Espero te sirva de algo aunque se escuche macabroso lo que hice.
Saludos.