Dos aplicaciones modificando el mismo registro ...
 

La situación es la siguiente, tengo dos programas, uno oculto que trabaja como un servicio y que va haciendo cambios en la base de datos, y otro visible en el que el usuario revisa los datos y puede hacer modificaciones.

El problema surge cuando el usuario esta viendo un registro y decide cambiarlo, sin saber que el otro programa, el oculto, ha borrado ya ese registro. Entonces se produce el "famoso" error de deadlock. También se produce un error cuando en vez de modificar ese registro, se modifica otro que depende de el, se produce un error indicando que se ha incumplido una de los "constrains".

Se que este es un error muy común, por eso recurro a vuestra experiencia para preguntaros cual es la mejor forma de solucionar esto. A mi se me ocurren varias formas: un botón para refrescar los datos, cerrar y volver a abrir la transacción antes de hacer los cambios, etc ... puede que sean "ideas de bombero" :o así que os pido vuestra opinión.

Mas datos:

1. Delphi 7
2. Firebird 2.0
3. WindowsXP
4. Utilizo los componentes de la paleta Interbase, Data Controls y Data Access

Ayudar a este novato diciéndole como resolvéis vosotros este problema, antes de que se ponga a reinventar la rueda :o

Gracias

Hola,

Una pregunta Domingo, ¿cada cuánto tiempo el servicio puede modificar registros? Mi experiencia en estos temas es más bien poca, pero, ¿no bastaría en principio con que el programa del usuario mostrase (justamente, al ser mostrado) los registros, la información, recién actualizada? Claro que si el Servicio modifica registros cada N segundos... No sé, no sé... :)

Hola Seaone,
Una solución seria tener tus querys de actualizacion con esquemas de oldValue=ValorActualEnTablas, es decir, que guardes los valores originales y cuando vayas a realizar algun cambio pues en tu where pongas la condicion de que el valor original deba de ser igual al valor en tablas para que la modifcacion pueda ser llevada a cabo. Bien otra opcion (para mi la mejor) es utilizando los ClientDataSet y DataSetProvider, con esta pareja ya no es necesario hacer a "mano" las querys de actualizacion, insercion y borrado, sino que en automatico te las genera el provider, aunque si se dan "errores" de actualizacion (como el que te da) te da la oportunidad de trartarlos y decidir que hacer.
Espero haberte ayudado.
Saludos

El problema es que el servicio puede modificar los datos en cualquier momento, y el programa del usuario puede estar abierto durante bastante tiempo, así que se tendrían que refrescar los datos, pero ¿cada cuanto tiempo?. Y además, aunque refrescáramos los datos periódicamente, nadie nos asegura que estén actualizados en el momento en que los vayamos a utilizar :(

Hola,

Sí... ya me suponía yo que mi idea era también de bombero... ¡torero! Pero aquí habrá quien le sepa tañer Domingo, ya verás, ya. :D :)

Gracias por contestar juanelo, ahora mismo uso los componentes TIBTable y TIBQuery. No hay problema para capturar el error, pero lo que todavía no he decidido es que hacer cuando se produce el error ¿refrescar los datos y avisar al usuario de que vuelva a intentarlo? :confused:

Podrias usar el Post_event de FireBird, de esa manera cada que el servicio cambie o borre dicho registro en la BD, podras enviar una "Señal" a tu aplicación y refrescar los datos "inmediatamente".

Mira,
Para el programa que tiene "interfaz con el usuario", pues lo mas recomendable es que le informes de la situacion (depende en realidad de la logica de negocios de tu app) pero ya tomada una desicion, es decir, imaginate que estas en programa de ventas y que en la pantalla de ventas te aparecen 10 unidades del articulo A, pero en el momento de llevar a cabo la venta (grabar) resulta que solo queda 5 y el cliente te esta solicitando 6, pues lo que yo haria es mandar un mensaje en donde le indico al usuario que no hay suficientes existencias para su orden (pero la desicion ya esta tomada, NO SE GRABO NADA DE LA FACTURA) y por supuesto le sugiero la nueva cantidad (refresco los datos). Ahora bien lo interesante viene en tu servicio, ya que este tiene que tomar las desiciones el solo, sin ayuda del usuario, lo mismo, esto depende de la logica de negocios que tengas.
PD: Puede usar ClientDataSet y DataSetProvider perfectamente con TIBQuery.
Saludos-

Me gusta esa idea, voy a probar. Si tengo problemas volveré :cool:

En el OnBeforePost del componente que utilizas (TIBTable) podrías verificar antes de grabar si los datos han cambiado.

- Select según la PK verificando que los demás datos sean iguales que los campos que tienes en la tabla.
- Si devuelve EOF, se ha borrado el registro

Si ya no existe --> Mensaje de error y refrescar la tabla o insertarlo nuevamente.
Si ha cambiado algo --> Quizás mensaje diciendo que alguien ya lo ha tocado antes
--> o No importa, se hace el post y el commit.

Personalmente, me parece mucho más facil que todo lo que estais comentando. :p

En la llamada al procedimiento que modifique el registro, lo que haces es un Refresh de ese registro en concreto, con lo que en el momento de editar tendrás la última actualización que se haya realizado.

Justo después del refresh puedes comprobar a su vez si fue borrado o no el registro, o por supuesto al hacer el refresh, entiendo que todos los 'dependientes' también se actualizarán.

Ya otro tema sería si te interesan actualizaciones 'periódicas' de los datos que en ese momento muestres en pantalla. Pero entiendo que eso es un asunto diferente.

Yo al menos me apaño muy bien con este método. ;)

Seoane,
considero que enviar una señal al programa abierto no es una solución 100% efectiva, ya que pueden coincidir el borrado del servicio/refresco/borrado de la aplicación en el tiempo.
Me gusta más la solución que te plantean anteriormente. Al borrar el registro, antes de realizar el borrado, comprobar que sigue existiendo. Si es así, se borra. Si no es así, sacar un mensaje de error para que lo vea el usuario diciendo "No se puede borrar porque ya no existe, los datos han caducado". o similar.
Si además te planteas que puede ocurrir muy a menudo, puedes bloquear el registro, para que quien borre el registro no lo haga si está bloquedo por otro usuario y/o en otra transacción. Ya de esto te podrán aportar más datos los expertos en firebird, ya que no tengo experiencia al respecto. Porque nadie te asegura quién será el que borre el registros, el servicio o la aplicación.

Espero haberte aportado algo.

Suerte y un abrazo - sin dead, de abrazo mortal 'dead lock' ;-)

PD: Vaya , gluglu se me adelantó

Incredible
El Sr. Seoane es humano, y también pregunta...:D:D

No había visto este hilo. La opción referida a Post_event, sería buena en el caso de que el servicio no hiciera muchos cambios, de otro modo, el programa del usuario/s estarían refrescando datos constantemente y podría interferir en el proceso normal de programa.

A mi juicio, lo mas simple yeficaz habida cuenta de lo dicho, sería comprobar que el registro a modificar existe antes de proceder a esa modificación, ni mas ni menos, Tal vez con un query alternativo o temporal.

O escribo lento, o este hilo está que arde... según escribí entraron dos mensajes...

Bueno, todo depende para lo que necesites, si necesitas que el usuario vea en tiempo "real" la manera como cambia dicha información el Post_event es una buena solución, pero si solo necesitas que el programa no deje tocar un registro que no existe porque se borro con el servicio que mencionaste, definitivamente las otras opciones son las mejores ;).

... para una vez que pregunta un maestro y uno puede ayudar ... :p :p

gluglu tiene razón,
cuando uno puede ayudar a un maestro, duerme esa noche a pierna suelta, como más contento.

Un abrazo

a mi me parecen valederas la dos soluciones cada una tiene pro y contras, la de jhonny con sus eventos se volveria ineficiente cuando hayan grandes cantidades de usuarios modificando la base de datos, estarias recibiendo mensajes cade segundo

la de gluglu y fjcg02 siempre y cuando los indices y la consulta este bien estructurada ya que si no tardarias un tiempo si la base de datos llega a crecer mucho

Si, soy humano :( ( ya te pillare preguntando sobre la API :p)

¿Que os parece esta idea?

Cuando hago una modificación capturo el error que se produce, aviso al usuario y refresco los datos. Además coloco un botón que permita actualizar los datos, para que el usuario pueda obtener información actualizada cuando lo desee.

Mira que me ha pasado lo mismo :D:D