problema con visibilidad de transacciones

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

[Galahad]

Empezado por Sick boy

Hola,

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.

bueno, aqui el tema es que tenia yo una confusión de conceptos, por derivación de paradox, hasta ahora el afterinsert erá el evento en el que
asignaba los valores por defecto que vé el usuario para empezar a crear un registro nuevo, error, el triguer before insert es el evento en el que se asignan los valores por defecto antes de grabar el registro.
por eso no me sirve el trigguer para dejar estos valores por defecto cuando (desde un mantenimiento) se crea un registro nuevo.

Empezado por Sick boy

¿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??

si, los fib tienen un componentes de transacción independiente del dataset, tengo una sola transacción, si que tiene la opción autocommit, la tengo a false, el caso es que he vuelto a instalar el servidor de firebird y... FUNCIONA !! , es decir ahora tengo el siguiente código en el evento datasetafterpost:
tpfibdataset( dataset).transaction.commitretaining;
dataset.refresh
es decir , ya no hago el :
dataset.close;
dataset.open;
dataset.locate( ...),
y funciona perfectamente, es decir , no tengo necesidad de volver a abrir la fuente de datos..

Empezado por Sick boy

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 el locate utiliza los índices para optimizar los índices ,por lo que no son una mala opción a utilizar si existen indices creados a utilizar (que alguién me rectifique si estoy equivocado

Empezado por Sick boy

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.

entiendo que en el contexto de un mantenimiento (uso intensivo de altas/bajas/modificaciones), es más aplicable el concepto del commitretaining,porque se requiere que la tabla quede abierta, en este
hilo hay un comentario al respecto, no obstante me gustaria conocer más opiniones al respecto.

un saludo

[Sick boy]

bueno, aqui el tema es que tenia yo una confusión de conceptos, por derivación de paradox, hasta ahora el afterinsert erá el evento en el que
asignaba los valores por defecto que vé el usuario para empezar a crear un registro nuevo, error, el triguer before insert es el evento en el que se asignan los valores por defecto antes de grabar el registro.
por eso no me sirve el trigguer para dejar estos valores por defecto cuando (desde un mantenimiento) se crea un registro nuevo.

Ufff, si no lo entiendo mal, tu incias los valores del siguiente registro justo despues de crear el anterior????
En mi opinion, esta mal, yo no lo haria.
Para valores por defecto, usa DEFAULT al crear la tabla.O inicialos en el evento de insercion, pero no añadas un registro extra, pensando que luego lo utilizaras.
Si no lo utilizas tendrás que borrarlo, o dejarias registros sin datos.

tengo una sola transacción, si que tiene la opción autocommit, la tengo a false,

En que parte de tu codigo haces el commit???
Sigue estando en el AfterPost??

creo el locate utiliza los índices para optimizar los índices

Si lo entendiese lo discutiria. Me reafirmo en no usar locate.

entiendo que en el contexto de un mantenimiento (uso intensivo de altas/bajas/modificaciones)

Lo siento, pero no se que significa un mantenimiento. Probablemente en españa tenga otro nombre, si me explicas el concepto seguro que te entenderemos.
A cuantas modificaciones por segundo se refiere "el uso intensivo"??

Y por cierto, actualmente no tienes ningun problema, verdad??

PD: Cuando digo que algo esta bien o esta mal, es mi opinion, cada uno despues hace lo que le parece mejor.

[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

[RolphyReyes]

Empezado por levanteelx

g
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 ?

Para esta parte debes de agregar en el ORDER BY la sentencia DESC del campo que tenga un indice de forma descendente.

Por ejemplo el campo fecha lo crearía con dos indices uno ascendente y el otro descendente entonces el query quedaría así:

Código SQL [-]
SELECT FIRST 20 *
FROM TABLA
ORDER BY FECHA DESC

O

Código SQL [-]
SELECT *
FROM TABLA
ORDER BY FECHA DESC
ROWS 20