13 respuestas en este tema

[Master23]

Quiero hacer una especie de Hilo de ejecución que compruebe de forma permanente si hay nuevos registros agregados en una base de datos x, para actualizar los datos de los grids y que siempre estén al día. Gracias de antemano espero puedan ayudarme en esta duda.

[luk2009]

Depende de que base de datos uses. Pero puedes usar los eventos de firebird para que te actualize los datos inmediatamente se genera algun cambio.  Que base de datos estas usando y que componentes? 

Si nos das mas informacion es mas facil ayudarte.

[Master23]

Depende de que base de datos uses. Pero puedes usar los eventos de firebird para que te actualize los datos inmediatamente se genera algun cambio.  Que base de datos estas usando y que componentes? 

Si nos das mas informacion es mas facil ayudarte.

Yo uso los componentes Zeos, y Uso MySQL,utilizo el ZQuery,ZConnection solamente.

[Marc]

Otra forma habitual es añadir una tabla LOG (registro) a la base de datos, y unos triggers After Insert/Update/Delete que después de cada operación con tus tablas, inserten un registro en la tabla LOG anotando la fecha, la operación (I/U/D), el ID de la Tabla Modificada y el ID del Registro Modificado.

Así cuando quieras consultar las modificaciones realizadas en la Base de Datos, solo tienes que leer esa tabla LOG.

Saludos.

[Sergio]

La sugerencia de Marc es la mas habitual y potente, pero si solo quieres detectar inserciones, y siempre que cada nuevo registro tenga un ID automatico tipo autoincremental (que es muy habitual, al menos en mis bases de datos lo uso mucho), puedes simplemente guardar el Max(Id) y cada rato mirar si ese Max(Id) se ha incrementado, y en ese caso, actualizas el grid y listo.

Aunque si tienes opcion de añadir los triggers como te indica Marc, tendras un sistema que no solo te avisa de inserciones, ademas puedes guardar el quien y el cuando se insertaron para temas de "yo no borre nada y ha desaparecido, tu aplicacion falla"... para eso, a la idea de Marc se le añade otra tabla de Log_Historico de forma que cada vez que detectas inserciones y actualizas tu grid, mueves esos records a la otra tabla (o los marcas como "leidos" en la tabla) y listo.

[Marc]

Siguiendo con la propuesta de Sergio de hacer un seguimiento de los ID's de la Tabla, me ha recordado otra forma muy sencilla y bastante usada de hacer un seguimiento de los registros cambiados.

Solo necesitas añadir un campo fecha/hora ULTIMA_ACTUALIZACION a cada tabla. Si cada vez que modificas un registro actualizas ese campo (ya sea desde tu programa Delphi o desde un trigger), entonces solo tienes que consultar los registros con ULTIMA_ACTUALIZACION mayor a la hora de la última vez que comprobaste buscando registros nuevos.

NOTA: Naturalmente es mejor tener la tabla de LOG, puesto que te mantiene un histórico de todos los cambios efectuados. Pero dependiendo de tus necesidades, con solo este campo de ULTIMA_ACTUALIZACION puedes tener bastante.

[Delphius]

Hola,
Me pareció haber leído por algún lado que MySQL si tiene algo parecido a los eventos de Firebird ¿O era Oracle?   

Si la idea es informar a las aplicaciones clientes a fin de "refrescar" los Grids me parece adecuado un enfoque basado en los eventos (En la jerga del tennis, diríamos que Firebird metió un ace    ). Ahora bien si no hay nada en MySQL parecido a los eventos no queda más que lanzar una instrucción SQL SELECT cada x tiempo por lo que es una lata... ya que inunda el motor de peticiones que en en algunos casos se podrían evitar debido a que no siempre se estará refrecando.

El punto es que el tema de Log solo serviría a efectos de auditoría, control. De una u otra forma, como he dicho: si hay que volver a refrescar se debe volver a ejecutar la consulta. Y en este caso, DOS: una para verificar en el LOG y la segunda ya para volver a mostrar los datos completos.

Saludos,

[luk2009]

la verdad es que no he trabajado con mysql, pero conozco a zeos y  si mysql no tiene algo similar a los eventos de firebird, una opcion es usar los eventos del zquery (afterinsert, afterpost,afterdelete,afterapplyupdate) para refrescar tu consulta y con ello estarias actualizando tus datos

[Sergio]

Luk, eso no valdria, es hacer trampas!

El cambio puede hacerse desde otro PC o desde otro continente, y esos eventos son locales de la aplicacion donde se hace la edicion, no refrescaria al resto de aplicaciones que pudiesen estar viendo esos mismos datos, que por lo que entiendo es la idea: ver lo que otros añaden a la tabla desde todos los programas.

Lo cual me recuerda que lo que yo propuse de un log, o de una tabla con las nuevas inserciones de Marc, ambas ideas son "de usar y tirar", es decir, que si A hace una insercion, y B refresca su grid, C ya no ve que hayan habido cambios (B los borro de la lista de inserciones), por lo que la solucion de Marc de guardar la ultima fecha de modificacion (incluyendo el alta como una primera fecha de modificacion) es lo recomendable, aparte de ser super sencillo por trigger usando algo tipo "last_mod = current_datetime" (si no me falla la memoria). 

[Marc]

Hola.

El cambio puede hacerse desde otro PC o desde otro continente, y esos eventos son locales de la aplicacion donde se hace la edicion, no refrescaria al resto de aplicaciones que pudiesen estar viendo esos mismos datos, que por lo que entiendo es la idea: ver lo que otros añaden a la tabla desde todos los programas.

En realidad estos eventos de bases de datos es una característica única de Firebird, y envía ese evento a todos los equipos de la Red que estén a la escucha para dichos eventos.

Aquí hay un buen artículo en castellano que explica como programar lo que sugiere Luciano.

http://www.firebird.....php?storyid=35

Saludos.

[Delphius]

Hola.

En realidad estos eventos de bases de datos es una característica única de Firebird, y envía ese evento a todos los equipos de la Red que estén a la escucha para dichos eventos.

Aquí hay un buen artículo en castellano que explica como programar lo que sugiere Luciano.

http://www.firebird.....php?storyid=35

Saludos.

Creo que no estamos mareando...
Se me hace que a los eventos que señaló Luciano no son los mismos eventos de Firebird. A menos que yo esté confundido.. Luciano mencionó que se puede contar con los eventos que cualquier dataset ofrece: AlfterPost, etc.

Luego Sergio le aclaró de que estos eventos son a nivel aplicativo.

Y por último tu has corregido a Sergio informándole que los dichosos eventos son exclusivos de Firebird y que el mismo motor se encarga de comunicar a los clientes registrados.

Me parece a mi que se han intentado corregir el uno al otro y no se han fijado bien a que eventos hacen referencia.  Hemos pasado a hablar de los eventos que ofrece Firebird, a saltar sobre los eventos de un dataset.

Saludos,

[enecumene]

Hola,
Me pareció haber leído por algún lado que MySQL si tiene algo parecido a los eventos de Firebird ¿O era Oracle?   

Pues claro, a partir de la version 5.1 implementaron esa opcion:

http://dev.mysql.com...sql-events.html

Saludos.

[Marc]

Hola Delphius.

Creo que no estamos mareando...
Se me hace que a los eventos que señaló Luciano no son los mismos eventos de Firebird. A menos que yo esté confundido.. Luciano mencionó que se puede contar con los eventos que cualquier dataset ofrece: AlfterPost, etc.

Luego Sergio le aclaró de que estos eventos son a nivel aplicativo.

Y por último tu has corregido a Sergio informándole que los dichosos eventos son exclusivos de Firebird y que el mismo motor se encarga de comunicar a los clientes registrados.

Me parece a mi que se han intentado corregir el uno al otro y no se han fijado bien a que eventos hacen referencia.  Hemos pasado a hablar de los eventos que ofrece Firebird, a saltar sobre los eventos de un dataset.

Sí, parece que tienes razón (Luciano al principio se refería a los eventos de Firebird, y después habló de los eventos del Dataset como alternativa, a eso es a lo que respondía Sergio).



 

 

[luk2009]

Pues sergio tienes razon, esto solo le serviria para actualizar la aplicacion que este utilizando en ese momento.
Pero si existen los eventos tipo firebird en mysql como indica enecumene, esa es la mejor opcion.