¿Cómo comprobar si hay cambios en los registros,de una base de datos?
#1
Escrito 23 febrero 2011 - 08:10
#2
Escrito 23 febrero 2011 - 08:18
Si nos das mas informacion es mas facil ayudarte.
#3
Escrito 23 febrero 2011 - 08:43
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.
#4
Escrito 24 febrero 2011 - 03:13
Así cuando quieras consultar las modificaciones realizadas en la Base de Datos, solo tienes que leer esa tabla LOG.
Saludos.
#5
Escrito 24 febrero 2011 - 03:36
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.
#6
Escrito 24 febrero 2011 - 04:05
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.
#7
Escrito 24 febrero 2011 - 06:59
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,
#8
Escrito 24 febrero 2011 - 06:23
#9
Escrito 25 febrero 2011 - 05:11
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).
#10
Escrito 25 febrero 2011 - 06:19
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.
#11
Escrito 25 febrero 2011 - 07:53
Creo que no estamos mareando...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.
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,
#12
Escrito 25 febrero 2011 - 08:14
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.
#13
Escrito 25 febrero 2011 - 09:36
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).
#14
Escrito 25 febrero 2011 - 07:55
Pero si existen los eventos tipo firebird en mysql como indica enecumene, esa es la mejor opcion.