Notificación de cambios en MSaccess

[Yps]

Hola a todos. espero que alguien me pueda ayudar con mi problema, que es el siguiente: accedo a una DB MSAccess desde dos programas hechos en Delphi. ¿Cómo puedo actualizar el dbgrid del programa 2, cuando inserto un registro desde el programa 1 ya que MSAccess no dispone de triggers y otras caracteristicas?

[Neftali [Germán.Estévez]]

Empezado por Yps

Hola a todos. espero que alguien me pueda ayudar con mi problema, que es el siguiente: accedo a una DB MSAccess desde dos programas hechos en Delphi. ¿Cómo puedo actualizar el dbgrid del programa 2, cuando inserto un registro desde el programa 1 ya que MSAccess no dispone de triggers y otras caracteristicas?

Access no posee "Database Alerts" o "Eventos de notificación" como se conocen y que soporta FireDAC (por ejemplo):
https://docwiki.embarcadero.com/RADS...lerts_(FireDAC)

Son eventos que sirven para comunicar desde la Base de Datos a tu aplicación (mediante los componentes de conexión) que ha habido cambios en alguna tabla:
https://neftali.clubdelphi.com/event...notifications/

Access, como bien dices, tampoco soporta triggers, aunque eso no te ayudaría a que la aplicación conociera si ha habido cambios.

La única forma que se me ocurre desde la aplicación es hacer un "pooling" periódico, o lo que es lo mismo, ir preguntando de forma periódica si ha habido cambios en la tabla para refrescar un Grid. Si esa query (por eficiencia) no quieres hacerla sobre la tabla de datos que estás mostrando, lo que se suele hacer es una pequeña tabla con un Timestamp (marca de tiempo), que te marca cuando ha sido la última modificación de la "tabla A" (y de otras tablas), de forma que desde tu aplicación debe ir haciendo el "pooling" a esta tabla (mucho más rápido, ya que es una tabla pequeña y con pocos campos y registros).

Si tienes una modificación pendiente, entonces actualizas el Grid (y eliminas el registro en la tabla de pooling); De esa forma te evitas ese refresco constante con muchos datos, que suele ser más costoso.
Para crear un registro es esa tabla de "pooling", sí que te ayudaría tener triggers (ya que podrías hacerlo de forma automática), pero en el caso de MSAccess deberás realizarlo tú de forma manual.

No se si me he explicado bien, espero que si.

[Casimiro Notevi]

Lo más simple es un Timer que haga un refresh de la tabla cada cierto tiempo.
Otra opción puede ser crear un ficherito en un directorio compartido entre ambos equipos y un componente que recibe una notificación del sistema cuando hay algún fichero nuevo en ese directorio. En ese momento haces el refresh.

[Yps]

Gracias por interesarte en mi problema!! La verdad es que había pensado en la solución con el timer. No la he implementado ya que tenía la esperanza de encontrar una solución mejor pero parece que tendré que recurrir al timer. Una vez más gracias por el interés.

[Yps]

En cuanto a lo del "pooling" la explicación a sido buena, aunque no sé cómo hacerlo, si no es mucho pedir podrías enviarme algún enlace donde se explique como implementarlo. Realmente me interesa!!

[Neftali [Germán.Estévez]]

Empezado por Yps

En cuanto a lo del "pooling" la explicación a sido buena, aunque no sé cómo hacerlo, si no es mucho pedir podrías enviarme algún enlace donde se explique como implementarlo. Realmente me interesa!!

El "pooling" no es más que lo que ha comentado [Casimiro]. Ir preguntando periódicamente por el estado de algo para saber si ha sufrido cambios (en este caso los cambios en la tabla).
La implementación con un Timer o con un thread separado.

Lo que si considero importante es, que si la tabla de la que quieres refrescar el Grid es muy grande, no pregunte directamente a la tabla (refrescando el grid), sino que lo hagas con una tabla secundaria (pequeña y de acceso rápido). Por ejemplo, si tienes una tabla de OPERACIONES que visualizas en un grid y quieres mantenerla actualizada, pero es grande, te creas una segunda tabla pequeña con esta estructura:

HAY_CAMBIOS_OPERACIONES
-------------------------------------

ID; Autonumerico;NOT NULL
ULTIMOCAMBIO; FechaHora; NOT NULL

1) Cuando hay un cambio en la tabla de operaciones, haces un INSERT en la tabla HAY_CAMBIOS_OPERACIONES
2) El pooling o el Timer hace la consulta sobre la tabla HAY_CAMBIOS_OPERACIONES, en lugar de sobre la tabla de OPERACIONES
(esto sale a cuenta si la tabla de OPERACIONES es pesada/grande y las consultas costosas)
a) Si la tabla HAY_CAMBIOS_OPERACIONES tiene registro, actualizas el GRID y borras ese registro
b) Si la tabla HAY_CAMBIOS_OPERACIONES NO tiene registros es que no habido cambios y no hay que hacer nada más.

Lo dicho, esta tabla HAY_CAMBIOS_OPERACIONES sale a cuenta mantenerla si la tabla OPERACIONES es grande y no quieres estar continuamente generando esas consultas costosas. Si la taba original (OPERACIONES) es pequeña o la consulta se hace con filtros y no es costosa, esta técnica de usar una segunda tabla no es necesaria.

Esta es la idea simple, hay variantes, como que la tabla HAY_CAMBIOS_OPERACIONES, sea más genérica y te pueda servir para más tablas. En este caso el TimeStamp no haría falta estrictamente, sólo que exista registro, etc, etc, etc,... (el ejemplo es simple y rápido para explicar la idea, no es una implementación final).

Espero que la idea se haya entendido.

[Yps]

muchas gracias por sus respuestas, gracias a ustedes por ayudarme en mi problema. también queria comentarles que había pensado en solucionar el problema usando sendmessage para enviar un mensaje desde el programa 1 al programa 2, pero no pude ya que el programa 1 es un servicio de windows y no me funciona findWindow para poder saber cual es el handle del programa 2