Sistema se pone lento con el paso de los dias.

[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.

[rastafarey]

Hermanito para las notificaciones es un pelo larga la explicacion asi que vamos a la pratica. bajete ibobject. Esos componenete stren un ejemplo que te lo explica como un niño de pechos y si encuentras los fuentras veras el codigo de la notificacin es una soberana estupides pero ocn una solucion muy inteligente y sencilla.