problemas de actualización con interbase y delphi

Giniromero · #1 19-05-2003

Hola a todos/as;

tengo una aplicación hecha con delphi 6 que funciona con interbase 6.

Esta aplicación la tienen que usar a un mismo tiempo varios usuarios, y tendría que aparecerles los campios que los demás hagan de un modo inmediato.

El problema es que esto no sucede.

tengo un database, y un transaction, que me controlan todas las TIbQuerys y las TIbTable.

¿Alguien puede ayudarme?

Gracias

Virginia

kinobi · #2 19-05-2003

Hola,

Cita:

Posteado originalmente por Giniromero
Esta aplicación la tienen que usar a un mismo tiempo varios usuarios, y tendría que aparecerles los campios que los demás hagan de un modo inmediato.

la única forma de aproximarse a la inmediatez que buscas es cerrando la transacción (commit) nada más aplicar los cambios y que los usuarios concurrentes reabran sus consultas (por supuesto con un nivel de aislamiento para sus transacciones igual a READ COMMITTED).

El control transaccional se basa en el aislamiento entre transacciones, mientras no cierres (commit) la transacción desde la que se están aplicando los cambios en la base de datos, el resto de transacciones (usuarios) no pueden "enterarse" de los mismos.

Saludos.

Bacterion · #3 19-05-2003

prueba a ver si el TIBEvents puede servir para eso, aunque lo que pretendes va un poco contra la filosofia del cliente servidor (creo).

kinobi · #4 19-05-2003

Hola,

hace tiempo, en los foros antiguos, recuerdo que se debatió el uso de los eventos InterBase para la sincronización de transacciones (usuarios).

En mi opinión, por supuesto discutible, no es buena idea. Los eventos InterBase es un mecanismo asíncrono de comunicación Servidor -> Cliente, insuficiente para la sincronización entre aplicaciones, y que además puede dar muy poca información de los "objetos" implicados en la base de datos; como mucho la tabla implicada y el tipo de operación, pero no los registros concretos implicados.

Además está el problema del tráfico de red que puede generar; no serían necesarias muchas transacciones para que se disparase hasta hacerse tal vez intolerable.

Por supuesto todo es cuestión de probar para casos concretos, pero como regla general yo lo desaconsejaría.

Saludos.

Giniromero · #5 20-05-2003

gracias, ya lo he solucionado

Virginia

Argaron · #6 22-05-2003

Oyer perdona yo tambien tengo el problema que tu dices y me gustaria si es posible que me indicaras como has echo para que los cambios se reflejen de manera automaticas en todos los clientes?

Giniromero · #7 22-05-2003

Hola,

Lo que hice fue, hacer doble click sobre mi transacción y ponerma en "ReadCommitted"

Después, todas mis tablas las vinculé con los siguientes dos procedures en eventos:

*Events --> AfterPost

procedure TForm1.TableAfterPost(DataSet: TDataSet);
begin
IBTransCenta.CommitRetaining;

end;

*Events --> AfterCancel

procedure TFrmMainCenta.TableAfterCancel(DataSet: TDataSet);
begin
IBTransCenta.RollbackRetaining;

end;

//donde IBTransCenta es el nombre de la transaccion que tengo asociada a mi BD

La llamada CommitRetaining es para almacenar constantemente en el servidor de la base de datos, todas las actualizaciones, inserciones, y cancelaciones de los datos asociados a la transacción actual y después para conservar el contexto de la transacción. (mira en el help de delphi)
La llamada RollbackRetaining es para deshacer en el servidor de la base de datos todas las actualizaciones, inserciones, y cancelaciones de los datos asociados a la transacción actual y después para conservar el contexto de la transacción. (mira el help de delphi)

espero que esto te sirva de ayuda.

Saludos
Virginia

kinobi · #8 22-05-2003

Hola,

un comentario con respecto a ...

Cita:

Posteado originalmente por Giniromero
IBTransCenta.CommitRetaining;

aunque el método CommitRetaining (que en realidad encapsula una llamada a la función del API isc_commit_retaining) es muy cómodo desde el lado cliente, tiene sus puntos débiles en el lado servidor, que pueden llegar a provocar una bajada de rendimiento importante en el mismo.

isc_commit_retaining cierra la transacción actual y crea una nueva aprovechando el contexto de la antigua, con el consiguiente ahorro de tiempo, pero como desventaja está que no lanza el mecanismo de recolección cooperativa de basura, vital para eliminar registros obsoletos en la Arquitectura MultiGeneracional (MGA) de InterBase. Este tipo de recolección de registros obsoletos sólo es lanzada con un hard-commit (una llamada a la función isc_commit, o método Commit en IBTransaction). El resultado del uso continuado de CommitRetaining es una degradación paulatina del rendimiento hasta que se haga una limpieza, bien forzada por un sweeping o por un backup/restore de la base de datos.

En mi página web: http://www.clubdelphi.com/users/kinobi tengo un documento donde se explica más el tema.

Saludos.