Dos aplicaciones modificando el mismo registro ...

[[seoane]]

Empezado por dec

¿cada cuánto tiempo el servicio puede modificar registros? ... ¿no bastaría en principio con que el programa del usuario mostrase (justamente, al ser mostrado) los registros, la información, recién actualizada?

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

[dec]

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.

[[seoane]]

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?

[juanelo]

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-

[[duilioisola]]

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.

[[gluglu]]

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

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.

[[fjcg02]]

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ó

[jhonny]

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 .

[[gluglu]]

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

[[fjcg02]]

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

Un abrazo

[[eduarcol]]

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

[[ArdiIIa]]

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

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.

[[ArdiIIa]]

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

[[eduarcol]]

Empezado por ArdiIIa

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

Mira que me ha pasado lo mismo

[Casimiro Noteví]

Yo también me inclino por comprobar antes si se ha modificado/eliminado el registro.
El post_event, en según qué condiciones, puede ser contraproducente.



Edito: Tendrás que "ver" qué hay en el registro antes de editarlo por el usuario, por si se ha modificado,
En caso de haberlo borrado el "otro" programa, no hay problema, dará error al intentar borrar algo que no existe, cuestión de controlarlo en un típico try except y presentarle el mensaje oportuno.

[paldave]

Se me ocurre que podrían abrirse las tablas con la propiedad Exclusive = True, mantenerlas cerradas y abrirlas solo cuando se vayan a modificar. Entonces el programa que no tiene prioridad para modificar las tablas (no sé cual de los 2 es) primero comprueba si ya están usándose, y si es así intenta más tarde, cuando el que tiene prioridad haya terminado de hacer los cambios y haya cerrado las tablas.

[[seoane]]

Empezado por ArdiIIa

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

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

¿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.

[[ArdiIIa]]

Empezado por seoane

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

¿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.

Supongo que te refieres a que cuando el usuario graba (post), capturas el error y haces lo demás...

y si es un registro grande, que el usuario se ha tomado media hora para modificarlo, luego le informas que todo su trabajo se ha ido al garete...

[[seoane]]

Empezado por ArdiIIa

Supongo que te refieres a que cuando el usuario graba (post), capturas el error y haces lo demás...

y si es un registro grande, que el usuario se ha tomado media hora para modificarlo, luego le informas que todo su trabajo se ha ido al garete...

Son registros pequeños, con unos pocos campos ¿te parece mal la idea?

[jhonny]

Empezado por seoane

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

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".