problema con visibilidad de transacciones
 

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.

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.

valores por defecto
 

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

resuelto con stored procedure
 

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

¿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

refresh
 

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

Hola,

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

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

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.

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

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.

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

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


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

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.

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

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

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.

Saludos.

Por lo que veo te estas complicando con el uso de los FIBPlus, ellos son hasta ahora los únicos componentes que utilizan el concepto de dos transacciones (Read/Write) lo que los hacen potentes para desarrollo Cliente/Servidor.

Te recomiendo visitar artículos y leer sobre las transacciones con FIBPlus.

El componente TpFIBDatabase tiene dos propieades DefaultTransaction y DefaultUpdateTransaction y a su vez el TpFIBDataSet tiene Transaction y UpdateTransaction. Las primera de ambos indica la transacción que utilizara para la lectura y la segunda la de escritura. Por ende debes de poner en tu DataModule dos componentes TpFIBTransaction configurados adecuadamente.

Así en el TpFIBDataSet en la propiedad Options marcas True la opción poRefreshAfterPost teniendo en cuenta la propiedad RefreshTransaction indique tkReadTransaction , con esto el componente actualizara la transacción larga (Read) la que indicaste en Transaction.

Particularmente utilizo la opción de AutoCommit para mantenimientos, esta opción hace por ti el Commit en la transacción de Escritura y con la opción que ya te mencione poRefreshAfterPost te refrescara la transacción.

Espero haberte ayudado....

mantenimiento
 

a ver si me explico mejor..

el contexto es el de un mantenimiento (pantalla típica de programa de gestión para dar de alta,modificar o borrar por ejemplo clientes). yo hasta ahora, en paradox, cuando el usuario empieza a completar por ejemplo un nuevo cliente, busco él último código existente en la bd y le pongo el codigo siguiente a la vista (siempre trabajando sobre componentes dbware), claro, no puedo hacer esta operación de 'busqueda del codigo que le toca al nuevo cliente' en la claúsula DEFAULT, y tampoco puedo hacerla en el Trigger before insert, porque este evento se activa cuando el usuario 'confirma/graba' los datos del nuevo cliente.
Pero bueno, eso ya ha quedado solucionado con un stored procedure desde la parte del cliente.

si, al final he dejado esto,,
dataset.commit;
dataset.close;
dataset.open;
dataset.locate( ...)
a mi tampoco me gusta el locate,, de hecho nunca lo he utilizado en mis programas con paradox, pero...., está es la única manera que he encontrado de que cuando acabo de editar un registro y confirmo los cambios, al usuario se le quede en pantalla el registro modificado (al hacer el commit se cierra el juego de datos, y al hacer el open el 'puntero' se queda en el primer registro). He probado los bookmarks, pero no funcionan.


yo tambien soy de españa.,,, (alicante)..., creo que ya he explicado para mí lo que es un mantenimiento.., a este particular, antes has comentado que no utilizas componentes dbware,, en este tipo de procesos de alta,borrado,modificaciones, como lo haces ?, ¿ vuelcas un único registro sobre los por ejemplo edits del form y haces que al navegar por ejemplo con una serie de botones se vaya cargando un único registro en dichos edits ?.
yo hasta ahora siempre he utilizado componentes dbware, y me preocupa el hecho de que voy a tener algunas tablas grandes (30.000 registros), me temo que si utilizo la estructura anterior de que cuando grabo un registro nuevo hago 'dataset.close - dataset.open', me estoy trayendo al cliente los 30.000 registros, no es algo nada óptimo me temo, 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.
disculpa sea tan pesado , pero es que tengo que cambiar muchas aplicaciones de paradox a firebird, unos cuantos centenares de forms y ya que voy a estar como mínimo un año , pretendo que la base principal sea lo mejor posible.

bueno, la cuestión es que ahora mismo, el mantenimiento, funcionar , funciona, pero claro antes de utilizar este mantenimiento como plantilla de otros 200-300 que voy a tener que hacer ,quisiera asegurarme de que el enfoque va a ser después el adecuado para una aplicación que pueda aumentar mucho de tamaño con facilidad.

.

totalmente de acuerdo, el intercambio de impresiones siempre es positivo a todos los niveles, gracias

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.

gracias por contestar

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 ?
gracias , buscaré más información sobre estos componentes, mucha suerte con la elaboración de estas plantillas

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

fibplus consulta sobre uso de 2 transacciones simultáneas
 

me ha servido de mucha ayuda

Gracias, he leido y estoy haciendo pruebas con el uso de las 2 transacciones , tal y como dijistes, en principio está todo bien, tengo que hacer mas pruebas, pero todo parece funcionar bien. Bueno, el único tema es que tengo que hacer un dataset.fullrefresh después del afterpost para que me posicione bien los registros en un grid, pero bueno,, funciona..
El tema es que , leyendo los artículos que me indicaste en la web de los fibplus, me encuentro esto:

[code] Los tfibdataset de los fibplus tienen la posibilidad de asignar 2 transacciones, de esa manera , se puede configurar una transacción larga 'de solo lectura'


estoy utilizando formularios de tipo master-detail, y tanto para el master como para el detail he configurado las mismas 2 transacciones, una de lectura y otra de escritura. ¿ es esto correcto ?.
He estado intentando encontrar el motivo por que indica que si se utilizan 2 transacciones no se pueden utilizar las master-detail links,, aparentemente me funciona bien, aunque el detail lo configuro 'a mano' no utilizo la propiedad 'datasource' del link del detail.

Saludos.

En la misma pagina que te sugerí tienen artículos sobre Master/Detail con FibPlus además tienen publicado ejemplos de todas sus funcionalidades ahí busca sobre el tema.