problema con visibilidad de transacciones

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

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

[Galahad]

me ha servido de mucha ayuda

Empezado por RolphyReyes

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.

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'

TpFIBDataSet can work with two separate transactions. SelectSQL can work in the context of one transaction and all modifying queries are executed in the context of the other transaction. This helps to avoid transaction conflicts in multi-user environment. But transaction settings greatly depend on your business model and application architecture. For example, if you use separate transactions and the AutoCommit mode you can not always use master-detail links, etc.

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.

[RolphyReyes]

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.

[Galahad]

a ver si me explico mejor..

Empezado por Sick boy

Ufff, si no lo entiendo mal, tu incias los valores del siguiente registro justo despues de crear el anterior????

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.

Empezado por Sick boy

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

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.

Empezado por Sick boy

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

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.

Empezado por Sick boy

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

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.

.

Empezado por Sick boy

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

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