problema con visibilidad de transacciones

[Galahad]

saludos..., estoy creando un mantenimiento en el que pretendo que
uno de los campos claves (codigobanco) se autoasigne en el Triguer de la base de datos 'beforeinsert'.
1.-) Cuando creo un nuevo registro en el mantenimiento, en la aplicación cliente no veo el valor de dicho campo clave en ningun momento, es decir
cuando creo un nuevo registro el valor del campo clave asignado por el triguer aparece vacio, incluso después de grabar el campo tambien aparece vacio, en cámbio, cuando cierro y abro la aplicación si que aparece automáticamente el registro con el valor asignado por el triguer correctamente. De hecho, incluso despues de grabar dicho nuevo registro ,hojeando la base de datos en el 'sql Manager' observo que se ha generado correctamente el valor del campo.
Utilizo el componente tfibdataset de los fibplus
2.-) Por otro lado, si en el evento afterinsert de dicho componente, intento asignar el foco de edifición en un dbedit con por ejemplo 'editnombre.setfocus', recibo un accesviolation ¿?

este es el código de la base de datos.

CREATE TABLE FAC_MAE_FABAN (
  EMPRESA VARCHAR(3) CHARACTER SET NONE NOT NULL COLLATE NONE,
  CODIGOBANCO INTEGER NOT NULL,
  NOMBREBANCO VARCHAR(40) CHARACTER SET NONE COLLATE NONE,
  ENTIDAD VARCHAR(4) CHARACTER SET NONE COLLATE NONE,
  SUCURSAL VARCHAR(4) CHARACTER SET NONE COLLATE NONE,
  DC VARCHAR(2) CHARACTER SET NONE COLLATE NONE,
  CUENTA VARCHAR(10) CHARACTER SET NONE COLLATE NONE,
  POBLACION VARCHAR(40) CHARACTER SET NONE COLLATE NONE,
  DIRECCION VARCHAR(40) CHARACTER SET NONE COLLATE NONE,
  PROVINCIA VARCHAR(20) CHARACTER SET NONE COLLATE NONE,
  TELEFONO DEF_TFNO_FAX,
  FAX DEF_TFNO_FAX,
  OBSERVACION BLOB,
  CUENTACONTABLE VARCHAR(8) CHARACTER SET NONE COLLATE NONE,
  CLAVELIBROPOSICION VARCHAR(10) CHARACTER SET NONE COLLATE NONE,
  RIESGOMAXIMOPAGARES NUMERIC(11, 2) DEFAULT 0.0,
  RIESGOMAXIMORECIBOS NUMERIC(11, 2) DEFAULT 0.0,
  RIESGOMAXIMO COMPUTED BY (RIESGOMAXIMORECIBOS+RIESGOMAXIMOPAGARES));


ALTER TABLE FAC_MAE_FABAN ADD CONSTRAINT PK_FAC_MAE_FABAN PRIMARY KEY (EMPRESA,CODIGOBANCO);


CREATE INDEX FAC_MAE_FABAN_IDX1 ON FAC_MAE_FABAN(NOMBREBANCO);


SET TERM ^ ;



SET TERM ^ ;

CREATE TRIGGER FAC_MAE_FABAN_BI FOR FAC_MAE_FABAN
ACTIVE BEFORE INSERT
POSITION 0
AS
DECLARE VARIABLE NULTIMO INTEGER DEFAULT 0;
BEGIN 
    
    nultimo = 0;      
    if (new.codigobanco is null) then
    begin     
      select max( codigobanco ) from fac_mae_faban Where (empresa = new.empresa) into :nultimo;
      nultimo = nultimo+1;
      new.codigobanco = nultimo;
    end   
 
    
END^

SET TERM ; ^

a ver si me pueden ayudar, estoy dandole vueltas, he imagino que tiene algo que ver con la visiblidad de las transacciones, pero no consiguo identificar el problema.

[Galahad]

me contesto a mi mismo....

En cuanto a la visiblidad , bueno, he podido solucionarlo simplemente cerrando y volviendo a abrir el dataset, el único problema es que al hacerlo, por defecto el dataset se desplaza al último registro, me gustaria conseguir que si por ejemplo el usuario confirma los cambios de edición del registro con el código 25, al confirmar los cámbios no se desplaze al registro con el código 41 (último).
Por otro lado, sigo sin conseguir visualizar el valor asignado por el triguer 'before insert' hasta que hago el post..., he estado haciendo pruebas con los componentes 'fibevents', pero me doy cuenta de que su función principal es la
'refrescar' los contenidos de la base de datos a otros clientes conectados.
saludos,, sigo buscando soluciones...

[Galahad]

simplemente comentar que estaba equivocado, los triggers before insert se ejecutan justo antes de efectuar la inserción del registro, no para suministrar valores por defecto iniciales que era mi intención.
al final lo he solucionado, llamando a un stored procedure desde el evento afterinsert del componente tfibdataset.
me queda por resolver el hecho de recuperar el puntero después de guardar una edición de un registro, al cerrar y abrir el componente, se posiciona en el último registro.
saludos...

[boreg]

¿Probaste con refresh?, con esto te refresca el registro en el que estás posicionado sin actualzar todo, de otra forma para posicionarte en el registro que quieres utiliza el locate de tu componente.

Saludos

[Galahad]

Empezado por boreg

¿Probaste con refresh?, con esto te refresca el registro en el que estás posicionado sin actualzar todo, de otra forma para posicionarte en el registro que quieres utiliza el locate de tu componente.

Saludos

gracias por contestar, bueno, realmente el refresh, funciona....., es decir el cursor se queda el registro editado, el problema es que al crear un nuevo registro,si por ejemplo he insertado el código 4,, una vez insertado, veo los registros (en un grid) con la siguiente codificación : códigos 4,1,2,3 ¿?.
al cerrar y volver a abrir el mantenimiento, aparece todo correcto

al final lo he solucionado haciendo
dataset.close;
dataset.open;
dataset.locate( 'registrox') // solo para los casos de edición.

aunque funciona, imagino que el cerrar y volver a abrir el conjunto de datos no es la mejor solución por el mayor consumo de registros que representa:

nota: en el efecto afterpost del dataset tengo la siguiente cadena

tpfibdataset( dataset ).transaction.commitretaining;

gracias por la ayuda...

[Sick boy]

Hola,

empezar diciendo que no uso los FIb, uso MDO, pero son similares.

simplemente comentar que estaba equivocado, los triggers before insert se ejecutan justo antes de efectuar la inserción del registro, no para suministrar valores por defecto iniciales que era mi intención.

No estoy de acuerdo. Precisamente yo lo uso para eso.
Tu mismo dices que te funciona, pero que no ves el dato añadido hasta que vuelves a abrir el dataset.
Entonces, asignar el valor funciona, el problema es que no lo ves en ese momento.

¿Estas seguro de que es la misma transaccion?? Los FIb tienen un componente de transaccion independiente del dataset??
Has comprobado la opcion (AutoCommit) por defecto del dataset??

al final lo he solucionado haciendo
dataset.close;
dataset.open;
dataset.locate( 'registrox') // solo para los casos de edición.

aunque funciona, imagino que el cerrar y volver a abrir el conjunto de datos no es la mejor solución por el mayor consumo de registros que representa:

Hombre, no es que este mal, pero yo nunca lo haria. Mira la documentacion de locate para ver como trabaja.
Si te preocupa el close y open, te deberia preocupar mucho más el locate, que no utiliza ningun indice para hacer la busqueda, y se trae todos los datos del dataset hasta encontrar el que coincide.

Creo que la opcion de usar bookmarks puede servirte mejor.

nota: en el efecto afterpost del dataset tengo la siguiente cadena

tpfibdataset( dataset ).transaction.commitretaining;

Tengo entendido que commitretaining historicamente no ha funcionado muy bien. Yo apenas lo uso.
Si funciona bien, lo que hacer es un commit de la transaccion, más la apertura del dataset asociado (y quizas me equivoque, pero creo que deberia colocar el cursor en el punto donde estaba anteriormente), lo cual efectivamente consume recursos, tiempo y red.

Puede que estes haciendo otras cosas que interfieran, si puedes poner más informacion, el codigo que utilizas, etc...

[RolphyReyes]

Empezado por levanteelx

además los componentes fibplus no tienen componentes dbware en los que se pueden limitar el número de registros que digamos se puedan 'cargar' por cada petición de refresco del cliente por ejemplo

No es necesario que los componentes DataSet tengan esta opción solo debes de limitarlos en tu sentencia SELECT . Para FireBird tienes las sentencias First y Rows.

Debes de saber además que los FIBPlus tienen los siguientes procedimientos:

• Refresh: Que ejecuta la sentencia que tengas definidas en la sección Refresh del componente TpFIBDataSet.
• FullRefresh: Este reabre el DataSet, esconde eventos inncesarios y trata de localizar el registro activo.

Te exhorto a que te documentes más sobre estos maravillosos componentes; en mis proyectos personales los utilizo además de que estoy trabajando en la creación de Plantillas para realizar todo el proceso de Altas, Bajas, Modificación y demás.

[Galahad]

gracias por contestar

Empezado por RolphyReyes

No es necesario que los componentes DataSet tengan esta opción solo debes de limitarlos en tu sentencia SELECT . Para FireBird tienes las sentencias First y Rows.

ok, con esto resuelto la carga inicial de registros, para muchas tablas pequeñas no es necesario limitar la información, pero pienso que para otras tablas más grandes, como clientes y/o artículos, si que es necesario filtrar la cantidad de registros que aparecen en los grids, una táctica de trabajo seria la de cambiar los botones de siguiente,anterior, por otros donde por ejemplo el usuario seleccionara, 'siguientes 20 registros','anteriores ..etc ...', o mejor aun , en casos de documentos (albaranes,facturas,pedidos), se me ocurre que lo ideal seria crear botones para por ejemplo: 'dia anterior','mes anterior' que sustituyan a los de siguiente/anterior registro.

tengo entendido que no se puede utilizar un select del tipo
select last 20 from .....
para recuperar los últimos 20 registros,,según el índice activo..¿ es correcto ?

Empezado por RolphyReyes

Debes de saber además que los FIBPlus tienen los siguientes procedimientos:

• Refresh: Que ejecuta la sentencia que tengas definidas en la sección Refresh del componente TpFIBDataSet.
• FullRefresh: Este reabre el DataSet, esconde eventos inncesarios y trata de localizar el registro activo.

Te exhorto a que te documentes más sobre estos maravillosos componentes; en mis proyectos personales los utilizo además de que estoy trabajando en la creación de Plantillas para realizar todo el proceso de Altas, Bajas, Modificación y demás.

gracias , buscaré más información sobre estos componentes, mucha suerte con la elaboración de estas plantillas