Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Conexión con bases de datos
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Conexión con bases de datos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 06-10-2004
Avatar de AGAG4
AGAG4 AGAG4 is offline
Miembro
 
Registrado: ago 2004
Ubicación: Los Mochis, Sinaloa, México
Posts: 1.420
Poder: 21
AGAG4 Va por buen camino
¿¿¿¿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.

Agradezco cualquier comentario.

Última edición por AGAG4 fecha: 06-10-2004 a las 21:04:23. Razón: Corrección
Responder Con Cita
  #2  
Antiguo 06-10-2004
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 24
kinobi Va por buen camino
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.

Última edición por kinobi fecha: 06-10-2004 a las 21:31:59.
Responder Con Cita
  #3  
Antiguo 06-10-2004
Avatar de AGAG4
AGAG4 AGAG4 is offline
Miembro
 
Registrado: ago 2004
Ubicación: Los Mochis, Sinaloa, México
Posts: 1.420
Poder: 21
AGAG4 Va por buen camino
oki

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.
Responder Con Cita
  #4  
Antiguo 06-10-2004
cesar_picazo cesar_picazo is offline
Miembro
 
Registrado: ene 2004
Posts: 65
Poder: 21
cesar_picazo Va por buen camino
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
Responder Con Cita
  #5  
Antiguo 07-10-2004
Avatar de AGAG4
AGAG4 AGAG4 is offline
Miembro
 
Registrado: ago 2004
Ubicación: Los Mochis, Sinaloa, México
Posts: 1.420
Poder: 21
AGAG4 Va por buen camino
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.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 22:00:34.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi