Sistema se pone lento con el paso de los dias.

[jcapitan]

Mil gracias por su apoyo y consejos, checaré bien lo que me recomiendan, y les comento como me fue.
De nuevo, Casimiro Notevi, rastafarey, Neftali, guillotmarc y a toda la comunidad de Club Delphi Gracias Mil.

[jcapitan]

Bueno aqui estoy de nuevo..

Estuve monitoreando la base de datos con Sinática Monitor, y veo solo una transacción viva por ip.

Mencionan que tengo que cerrar la transacción lo mas pronto posible, pero como mantengo información en tiempo real en un grid para los usuarios, es decir cuando alguien modifique un registro se refleje en los demás.

Ando muy perdido en cuanto las transacciones segun veo. Ojala me puedan recomendar una lectura o ejemplos. Para aplicaciones de este tipo.

Les menciono la aplicación, los usuarios estan divididos en 2 grupos.
Grupo 1. Reciben llamadas y capturan información en "papeletas".
Grupo 2. Visualizan en tiempo real lo que el Grupo 2 está capturando, y atiende una de ellas metiendo información también en esta papeleta; si un usuario del grupo 1 cambió un campo del registro, en el grid que tiene en pantalla se muestra el cambio en tiempo real.

(Realmente todos ven lo que los demas capturan, pues tienen ventanas abiertas con grids que muestran información de folio, dirección, etc)

Cuando se cierran las papeletas (ya fueron atendidas) se mueve la información a otra tabla que es el historial (esta no la tienen pantalla pues son una cantidad muy grande de registros), de esta manera los refresh sera sobre la tabla que no tiene tantos registros, creo que de esta manera es más óptimo, si estoy mal por favor me corrigen.

En este caso como debo manejar las transacciones si es necesario que la información se esté refrescando y en pantalla.

[Gallosuarez]

JCapitan:

Tengo un pregunta: ¿Cual es el mecanismo que utilizas para poder ver que alguien ha hecho un inserción o modificación en las tablas de datos?

Quiero suponer que ese mecanismo lo estás implementando utilizando Eventos desde el mismo motor de la base de datos. Si no es así, el hacerlo a través de un "pooling" te degrada muchísimo el desempeño de la base de datos. Y por ahí puede estar el problema.

Saludos,
Gerardo Suárez Trejo

PD. Es mas eficiente ver la información en tiempo real cuando cualquier usuario hace un "commit" (ya sea para insertar o modificar un registro) y se lanza un aviso a través de un evento a todos los usuarios que se hayan suscrito a dicho evento.

PD2. Ouch!, no había leido bien tu "post" donde dices que manejas eventos, para poder ver cuando hay cambios en la base de datos. Me imagino entonces que implementaste una forma de leer solo el registro que se haya modificado o insertado (no cargar nuevamente todo el Dataset). Y asegurate de cambiar el Time Out a 1 (es de suma importancia para que las transacciones se hagan inmediatamente). Saludos nuevamente ...

[jcapitan]

Efectivamente lo hago através de eventos desdela base de datos.

Los cuales los tengo nombrados como
post_mod_regs_reales
post_mod_regs_detalles
...
..
. etc

los cuales los tengo capturados en el sistema con el componente TSIBfibEventAlerter, pero como mencionas realmente hago un fullrefresh de la tabla es decir de la consulta.

Esta de esta forma: en un ventana muestro registros que estan en espera de ser atendidos (con estatus 1), en otra ventana los registros que estan siendo atendidos (estatus 2), y se pasan a la tabla de historial cuando el estatus es 3 (cerrados)

por lo que las consultas de las 2 ventanas (en espera y en atención) es una consulta sobre la misma tabla solo con parametro diferente (el estatus).

Estuve buscando información para actualizar como tu dices solo el registro que se modifico y no traer toda la consulta de nuevo pero no supe como hacerlo, es decir saber el folio (la llave) que sifrio cambio y traer solo ese registro. Si es posible esto le agradeceré me iluminen para aplicarlo.


Ahora, esto es lo que posiblemente me este alentando la aplicación con el paso de los dias???

Gracias, si necesitan mas información de la aplicación la pongo de inmediato.

[jcapitan]

Espero y no haya problema por poner una imagen mostrando como funciona la aplicación (a groso modo obviamente).

Pues como se muestra en la imagen, se muestran dos ventanas con su respectivo grid mostrando la información de acuerdo a la consulta (estatus 1 o estatus 2), el usuario puede tener abierta 1,2 o mas papeletas si así lo requiere y a la vez modificar cualquiera, y ese cambio se refleja en los grids y en las papeletas que tengan abiertas los demas usuarios, esto lo hago a través de eventos. y si pongo el timeout a 1 la información en los grid y las papeletas no se muestra y me dice que la tabla esta cerrada.

Espero y se pueda mejorar esto con su ayuda. Gracias.

[jcapitan]

He checado con gfix -list , para que me muestre las transacciones que esten en el limbo y no me muestra alguna, esto quiere decir que no va por ese lado. Estuve leyendo por ahi que utilizando el gfix -sweep de manera manual me ayudara en que mi sistema no se sienta lento ya que por default lo tiene activado de manera automatica y puede ejecutarse en un momento en que los usuario esten haciendo mucho movimientos, y lo sientan lento.

Otro que se me ocurre es que las actualizaciones (refresh) que le hago a las tablas y a la vez a las papeletas (campos, variables, etc) las haga através de threads para evitar el retardo de actualización, ya que esto creo que es el retardo que ven los usuarios.

Tengo que probar, no se si hay algo más que pueda hacer para mejorar la velocidad de la aplicación. Algo más por checar.

Gracias.

[Gallosuarez]

JCapitan:

Yo lo haría de la siguiente forma:
1.Crear una tabla de cambios (bitácora de cambios). Crear una secuencia para esta tabla (SEC_BITACORA_CAMBIO). Crear un Trigguer (Aferter Insert/Update).

Código SQL [-]
CREATE TABLE BITACORA_CAMBIOS (
    ID            INTEGER NOT NULL,
    TIPO          CHAR(1) COLLATE ES_ES_CI_AI,
    TABLA_NOMBRE  VARCHAR(31) COLLATE ES_ES_CI_AI,
    ID_REGISTRO   INTEGER,
    DIA_HORA      TIMESTAMP,
    USUARIO       VARCHAR(31) COLLATE ES_ES_CI_AI
);

COMMIT;

ALTER TABLE BITACORA_CAMBIOS ADD CONSTRAINT PK_BITACORA_CAMBIOS PRIMARY KEY (ID);

CREATE INDEX BITACORA_CAMBIOS_IDX1 ON BITACORA_CAMBIOS (DIA_HORA);

COMMIT;
SET TERM ^ ;

CREATE OR ALTER TRIGGER BITACORA_CAMBIOS_AIU0 FOR BITACORA_CAMBIOS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
BEGIN
  POST_EVENT 'Cambio';
END
^

SET TERM ; ^

COMMIT;

CREATE SEQUENCE SEC_BITACORA_CAMBIOS;
ALTER SEQUENCE SEC_BITACORA_CAMBIOS RESTART WITH 0;

COMMIT;

2. Crear Procedimiento Almacenado para registrar los cambios

Código SQL [-]
SET TERM ^ ;

CREATE OR ALTER PROCEDURE REGISTRA_CAMBIO(
    TIPO CHAR(1),
    TABLA_NOMBRE VARCHAR(31),
    ID_REGISTRO INTEGER)
AS
BEGIN
  INSERT INTO BITACORA_CAMBIOS
    (ID, TIPO, TABLA_NOMBRE, ID_REGISTRO, DIA_HORA, USUARIO)
  VALUES
    (GEN_ID(SEC_BITACORA_CAMBIOS, 1), :TIPO, :TABLA_NOMBRE, :ID_REGISTRO, CURRENT_TIMESTAMP, CURRENT_USER);
END^

SET TERM ; ^

3. Crear Triggers (After Insert/Update) para TODAS las tablas donde deseas saber si hubo cambios (pongo esto porque no se los detalles de esas tablas)

Código SQL [-]
IF (INSERTING) THEN
  EXECUTE PROCEDURE REGISTRA_CAMBIO 'I', 'Pon aqui el nombre de la tabla', NEW.ID <-(Pones aquí el ID de tu tabla);

IF (UPDATING AND (
  NEW.NOMBRE IS DISTINCT FROM OLD.NOMBRE OR
  NEW.APELLIDO IS DISTINCT FROM OLD.APELLIDO OR
  ETC, ETC, (Debes poner los campos donde quieras saber si hubo un cambio)
)) THEN
  EXECUTE PROCEDURE REGISTRA_CAMBIO 'C', 'Pon aqui el nombre de la tabla', NEW.ID <-(Pones aquí el ID de tu tabla);

3.Con esto tienes para saber exactamente en que tabla, y cual fue el registro que cambió después de una inserción o algún cambio.
Ahora, desde tu aplicación tienes que ejecutar una SQL para traer solo los últimos campos que se han insertado o sufrido un cambio. Al leer el campo de TIPO de la tabla BITACORA_CAMBIOS, si contiene un valor 'I', entonces fue una inserción, si tiene un valor de 'C', entonces fue un cambio.
Hay un parametro (no recuerdo cual es), de tus FIBPlus que te dice cuantas veces se ha disparado el POST_EVENT y este te sirve para saber cuantos campos tienes que leer o refrescar ¿Me explico?

Atte:
Gerardo Suárez Trejo

PD. Espero que te algo te sirva esto. Solo resta hacer una pequeñas adecuaciones para refrescar leer o refrescar el campo que se inserto. Si tienes dudas en esto dime y te lo explico un poco detallado (ya no quiero hacer mas largo este "post").

[jcapitan]

Mil gracias, probaré la solución planteada, si salen algunas dudas te las comunico. Gracias.