Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   OOP (https://www.clubdelphi.com/foros/forumdisplay.php?f=5)
-   -   Evitar cerrar DataSet al abrir otro formulario (https://www.clubdelphi.com/foros/showthread.php?t=93282)

mRoman 13-07-2018 21:39:04

Evitar cerrar DataSet al abrir otro formulario
 
Buenas tardes amigos.

Trabajo con: Delphi6, FireBird 2.5, Win7, Componentes IBX.

Explico: Estoy intentando abrir un formulario (frmCatalogo) desde otro, donde registro un catálogo de las localidades que han asistido en comisión a realizar alguna actividad (frmLugaresComision). Este es llamado desde el menú principal y puedo realizar los clásicos movimientos de alta, baja, cambios, etc. sin ningun problema y luego tengo otro formulario (frmRequisicion) donde estoy registrando los datos de empleados que realizaran alguna requisición/comisión, entonces en este formulario, llamo al formulario del catálogo, pero este al abrirlo me cierra el DataSet del formulario de Requisiciones, lo anterior es porq en el formulario del catálogo tengo lo siguiente:

Código Delphi [-]
procedure TLugarComision.FormShow(Sender: TObject);
begin
      dsLugarCom.Transaction.Active:=False;
      dsLugarCom.Transaction.StartTransaction;
end;

Ya comprobé que sí quito la transacción del catálogo frmLugaresComision, el DataSet que esta en Requisiciones no se cierra, entiendo que esto pasa por el tema de transacciones, que tanto en Requisiciones como en el Catálogo, inicio una transacción, entonces estoy iniciando 2 a la vez (solo cuando abro el formulario de Catálogo desde el formulario de requisiciones), mientras no de click sobre el botón que abre el formulario del catalogo, no pasa nada, todo bien, se graban los datos.....entonces:

¿Que opciones existen para evitar que el DataSet del formulario frmRequisicion se cierre?
¿Que cambio debo de hacer en el formulario frmLugaresComision o en frmRequisicion?

Espero haberme explicado, en espera de sus comentarios....me estaré hechando un tequila:D

Casimiro Notevi 13-07-2018 22:29:30

¿Para qué inicias ahí una transaction?

mRoman 13-07-2018 23:12:07

Te refieres a iniciarla en el evento OnShow?
y adelantándome un poco....donde crees que quedaría mejor?

Alex Mireles 13-07-2018 23:23:00

Veo que estas combinando dos conceptos diferentes.

El Show o Create de la 2da forma NO tiene actividad de base de datos por el hecho de mostrarse, por consecuencia el StartTransacction no tiene sentido ahi , tendría sentido en algún botón que de inicio a alguna actividad con la Base de Datos.

El StartTransacction es una habilidad de la base de datos que te permite hacer recuperación de actualizaciones de datos que estén anidadas o dependientes de otras mas, es decir poder hacer un ROLLBACK o deshacer cambios aplicados por condiciones no concretadas.. . Si tu duda es como asegurar los datos últimos, busca hacer Commit Transaction para asegurar la ultima escritura o actualización que tenga pendiente el manejador de base de datos.

Saludos.

Casimiro Notevi 13-07-2018 23:24:10

Cita:

Empezado por mRoman (Mensaje 527603)
Te refieres a iniciarla en el evento OnShow?


Cita:

Empezado por mRoman (Mensaje 527603)
y adelantándome un poco....donde crees que quedaría mejor?

En ningún sitio, en principio no hace falta.
No sé cómo tienes configurado los componentes IBX (IBDatabase e IBTransaction), pero si usas uno para el programa, y están configurados correctamente, NO necesitas estar controlando transacciones porque el propio componente ya lo hace.

mRoman 13-07-2018 23:49:49

Cita:

Empezado por Alex Mireles (Mensaje 527604)
Veo que estas combinando dos conceptos diferentes.

El Show o Create de la 2da forma NO tiene actividad de base de datos por el hecho de mostrarse, por consecuencia el StartTransacction no tiene sentido ahi , tendría sentido en algún botón que de inicio a alguna actividad con la Base de Datos.

El StartTransacction es una habilidad de la base de datos que te permite hacer recuperación de actualizaciones de datos que estén anidadas o dependientes de otras mas, es decir poder hacer un ROLLBACK o deshacer cambios aplicados por condiciones no concretadas.. . Si tu duda es como asegurar los datos últimos, busca hacer Commit Transaction para asegurar la ultima escritura o actualización que tenga pendiente el manejador de base de datos.

Saludos.

Gracias por contestar muchachos.

La idea es facilitarle al usuario el ir al menú para seleccionar la pantalla de catálogos...me gustaría que desde el formulario de Requisición la abra directamente al dar click sobre un botón.

Alex, la pantalla de catálogo de lugares la construí pensando en que el usuario selecciona la opción desde el menú principal, entra y graba los lugares de comisión a los que a ido o irá, para luego ser seleccionados en la pantalla de requisiciones....de esta manera trabaja bien. El problema se me presentó al mandar llamar el catálogo desde el formulario de requisición. En fin se puede resolver no abriéndolo desde requisiciones.

CASIMIRO, en cuanto a que no es necesario las transacciones y de como están configuradas, te puedo comentar que en otros hilos donde tenia problemas acerca de registro de datos en un ambiente cliente-servidor (el cual es el caso en este momento), se debía a que no usaba el manejo de transacciones, dándome el problema de que los demás usuarios no veían los datos registrados...hasta que el otro usuario se salia del sistema. Esto se resolvio con el uso Startransaction y CommitRetainig/commit y desde entonces desarrollo de esta manera...sin no uso las transacciones tendré estos problemas....o como le haces tu?.

Pues la idea amigos, es: QUE DESDE EL FORMULARIO DE REQUISICIONES ABRA, DANDO CLICK EN UN BOTÓN, EL FORMULARIO DE CATÁLOGOS PARA QUE AGREGUE MAS LUGARES, SI NO ESTÁN REGISTRADOS. (no interpreten mal las mayúsculas por fa, no estoy "gritando" :) )

La otra opción es, no mandarlo llamar jajajaja:D....y hacer q el usuario lo seleccione desde el menú principal (el formulario del Catálogo) y vuelva abrir las requisiciones e iniciar de nuevo su captura.

Saludos y gracias por sus comentarios.

mRoman 14-07-2018 00:34:16

Otra opcion valida y quedó resuelto
 
Que tal, pues analizando las opciones que les plantee de "...que no se mande llamar del formulario de requisiciones, el formulario de catálogos...", pues les comento que la opción (abrir pantalla de catalogos) la quite del menú principal...y mejor opté por llamarlo desde el formulario de requisiciones....y bajo el concepto de transacciones (Gracias al Alex Mireles por sus comentarios) me di cuenta que podía almacenar todo lo q estaba pendiente de ser grabado usando 1 sola transacción, grabando en las base de datos, los lugares nuevos q el usuario haya dado de alta -en caso de que lo haya hecho- junto con los datos de la requisicion, al dar commit, se registraron todos los datos que estaban pendientes....

Por lo tanto el problema no fue de programación, si no -yo creo- de conceptos de diseño y como "acomodar" las virtudes de las trasacciones al grabar los datos.

Saludos.

rastafarey 14-07-2018 21:42:35

Respuesta
 
Bueno de verdad que tengo muchísimos años que no realizo programación tradicional, solo modelo vista controlador o aplicaciones n capas. Imagino que estas usando dbaware(DBEdits, DBGrid y esa cosas), pero lo más recomendable es jamás tener transacciones abiertas ya que estarías dando el control de tu aplicación los usuarios digo por mantener transacciones abiertas por mucho tiempo, imagina que el usuario abre la ventana donde inicias la transacción y se va comer, eso no está bien, debes iniciar la transacción al maneto de atacar dicha base de datos y asegurarte de cerrarla, porque eso te podría llevar a estar dejando transacciones en el limbo, y es allí donde las aplicaciones se pone insoportables.

Y para tu respuesta, llama a tu formularios y inicias y cierras la transacción solo cuando se anecesario.

mRoman 25-07-2018 16:23:59

Cita:

Empezado por rastafarey (Mensaje 527615)
Bueno de verdad que tengo muchísimos años que no realizo programación tradicional, solo modelo vista controlador o aplicaciones n capas. Imagino que estas usando dbaware(DBEdits, DBGrid y esa cosas), pero lo más recomendable es jamás tener transacciones abiertas ya que estarías dando el control de tu aplicación los usuarios digo por mantener transacciones abiertas por mucho tiempo, imagina que el usuario abre la ventana donde inicias la transacción y se va comer, eso no está bien, debes iniciar la transacción al maneto de atacar dicha base de datos y asegurarte de cerrarla, porque eso te podría llevar a estar dejando transacciones en el limbo, y es allí donde las aplicaciones se pone insoportables.

Y para tu respuesta, llama a tu formularios y inicias y cierras la transacción solo cuando se anecesario.

Ok gracias por contestar.

De hecho así lo hago, solo la transacción la inicio cuando se abre el formulario y la cierro cuando se da click sobre el botón grabar.....

Casimiro Notevi 25-07-2018 18:27:58

Cita:

Empezado por mRoman (Mensaje 527764)
De hecho así lo hago, solo la transacción la inicio cuando se abre el formulario y la cierro cuando se da click sobre el botón grabar.....

¡¡¡No, la transacción, si tienes que usarla, solamente en el momento de grabar, para que dure lo menos posible!!!
Código:

iniciar transacción
try
  ejecutar query
finally
  finalizar transacción
end;


ecfisa 25-07-2018 21:04:28

Hola.

Puede resultar interesante agregar que los componentes IBX, brindan la posibilidad de ajustar la propiedad TIBTransaction.IdleTimer la cuál permite asignar el tiempo máximo que la transacción puede permanecer ociosa antes de aplicar la acción asignada a la propiedad TIBTransaction.DefaultAction.

También permite aprovechar el evento TIBTransaction.OnIdleTimer que ocurre cuando la transacción ha agotado el tiempo definido.

Saludos :)


La franja horaria es GMT +2. Ahora son las 12:22:21.

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