Cuantos TIBDataSet estan abiertos

[sierraja]

Buenas noches, de que manera se podria chequear cuantos tibdataset estan activos. EL problema radica en que estoy utilizando un transaction y cada vez que hago un post o un delete ejecuto un dm.ibtransaction.commintretaing, pero resulta que en una aplicacion cliente/servidorta que no se cierra dicha transaction no podra ser vizualizada por los demas usuarios. Y lo que he leido es que se debe utilizar un commit, pero al realizar el commit me va a cerrar todos los tibdataset que estaban abiertos y eso me podria traer problemas. O de que manera se puede resolver que cuando se modifica en un pc se pueda visualizar de una vez en los demas pc. Tulizo ibx, delphi 7 y firebird 1.5. Gracias por su atencion....

[afxe]

Suelo trabajar con ibTransaction y commitretaining y no tengo ese problema (creo). ¿Qué parameters usas para la transacción? yo uso estos:

read_committed
rec_version
nowait

Puede también que sea un problema de uso. Yo suelo tener una transacción para cada formulario, no una común para todos, de manera que después de dar de alta o modificar un registro la transacción termina.

Saludos.

[defcon1_es]

Hola, el componente IBDataBase tiene dos propiedades heredadas de TCustomConnection, que son DataSetCount y DataSets[x].

Asi que para saber los datasets asociados a un IBDatabase, podría servir esto:

Código Delphi [-]
...
var i: Integer;
...
  for i := 0 to DataSetCount - 1 do
    if (DataSets[i] <> nil) and (DataSets[i].Active) then
    begin
       // Pon tu codigo aqui
    end;
...

NOTA: Si compilas con la directiva "Complete boolean eval" {$B} activada, usa mejor este codigo para prevenir errores:

Código Delphi [-]
...
var i: Integer;
...
  for i := 0 to DataSetCount - 1 do
    if (DataSets[i] <> nil) then 
      if (DataSets[i].Active) then
      begin
         // Pon tu codigo aqui
      end;
...

[sierraja]

Ok, gracias defcon1_es es justo lo que necesito, esto servira para solucionar el uso del commitretaing, pero el caso es que un usuario modifica un registro en un pc, otro usuario en otra pc vea los cambios realizados sin ningun problema, o de que manera se podria hacer esto o como seria el deber ser del commitretaing para evitar el lock dead de un registro.

Gracias afxe, me podrias dar mas detalles para tratar de solucionar mi caso segun tu aplicacion, ya que tengo commitretaing despues de un post y un delete y quisira plainificar esos cambios o evaluar cual es la mejor opcion para soucionar esta situacion.

Gracias por su valioso tiempo...

[afxe]

No hay mucho más que decir... Por ejemplo, creo un form para dar de alta un cliente, pongo un TIBTransaction asociándolo con el TIBDatabase correspondienet (normalmente solo uno en un TDataModule compartido por todos los forms) y el TIBDataSet correspondiente con la propiedad transaction apuntando al TIBTransaction del propio form, no el que tenga el TIBDatabase por defecto. Solicito todos los campos y cuando pulsa el botón grabar haces un commit al TIBTransaction creado en el form. Se comiteará y cerraran todas las tablas del form asociadas a esa transacción, insisto, sólo las tablas de ese formulario, pero si hay más dataset abiertos en otros forms activos no se verán afectados. En síntesis: cada formulario abre y cierra su propia transacción.
Saludos.

[sierraja]

Gracias por tu valioso tiempo. Es decir, tendria que modificar cada formulario para agregar una TIBTransaction y asociarla con el TIBdatabase del TDataModule y al momento de hacer una modificacion sobre las tablas involucradas (en dicho formulario), se debe hacer asignar en el TIBDataBase la TIBTransaction del formulario se inicia la transaction y luego del post se hace un commit a la trasaction del formulario:

Código Delphi [-]
    dm.ibd_agua.DefaultTransaction:=FFactura_guardada.IBTransaction1;
    FFactura_Guardada.IBTransaction1.StartTransaction;
    dm.ibds_Control.Edit;
    dm.ibds_Control.FieldByName('numero_factura').AsInteger:=StrToInt(Edit1.Text);
    dm.ibds_Control.Post;
    FFactura_Guardada.IBTransaction1.Commit;
    dm.ibd_agua.DefaultTransaction:=dm.IBTransaction1;

Luego realizar estos cambios sobre cada proceso y/o formulario ? De todas maneras realizare lso cambios a ver como funciona

Nota: EL proyecto trata sobre un sistema de facturacion y en el ejemplo arriba estoy guardando el numero de la factura. Utilizo Delhpi 7, IBX, FireBird 1.5.

Gracias nuevamente....

[afxe]

No hace falta cambiar la transacción por defecto del componente TIBdatabase, así que quitaría la primera y la última línea de tu código. Yo tampoco tendría el fichero de facturas ibds_control en el data module, sino directamente en el form donde tienes el Edit1 y la IbTransaction1. Eso te reportará algunas ventajas, sobre todo si permites abrir varias facturas a la vez. Si usas un sólo datamodule para toda tu aplicación te perderás entre tantos datasets, así que, o creas un datamodule para cada form o metes los datasets, datasources y ibtransactions en el form donde vaya a usarlos, y utilizas un sólo DataModule para el ibdatabase, para no tener muchas conexiones abiertas contra el servidor.

Saludos.

[[Lepe]]

afxe, me ha gustado mucho tu solución.

¿Se podría complementar con herencia visual?

Pensando en voz alta:
-Crear un form llamado TBaseForm añadiendo un TIBransaction, un TIBdataset y el uses al datamodule principal de la aplicación (para tener acceso al TIBDatabase).
- En TBaseForm, crear propiedades (property) para acceder cómodamente a los 2 componentes anteriores, además de un par de rutinas para hacer commit y rollback cómodamente.

Ahora, cuando quiera crear una nueva ventana, heredo visualmente de TBaseForm, con lo cual tendría:
- una nueva ventana
- un transaction asociado sólo a esa ventana
- Por defecto un TDataset que se usaría para los datos principales del Form.
- facilidades para hacer commit o rollback.

¿qué opináis?

Saludos

[rastafarey]

sin leer mucho. Y no respondiendo directamente a tu pregunta lo primero que deberias leer son las ventajas, desventajas y el como trabaja el commintretaing.