Dos aplicaciones modificando el mismo registro ...

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

[[seoane]]

Bueno, si nadie tiene objeciones lo voy a montar así:

- El usuario indica que quiere modificar un registro.
- Compruebo los cambios en el registro, y si ha cambiado aviso al usuario.
- Actualizo el registro.
- Capturo los posibles errores, y si se producen, actualizo y le indico al usuario que lo vuelva a intentar.

Muchas gracias a todos

[[Caral]]

Hola
Pregunto IB, no permite transacciones?

Código Delphi [-]
 DataModule1.AC1.BeginTrans;
// lo que se va ha hacer
DataModule1.AC1.CommitTrans;
//y si hay algun problema se crea una Exception
on E:Exception do DataModule1.AC1.RollbackTrans;

En ese orden.
Solo pregunto, porque cuando se hacen este tipo de cosas, se pueden perder datos, me parece.
Saludos

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

Empezado por seoane

- El usuario indica que quiere modificar un registro.
- Compruebo los cambios en el registro, y si ha cambiado aviso al usuario.
- Actualizo el registro.
- Capturo los posibles errores, y si se producen, actualizo y le indico al usuario que lo vuelva a intentar.

Bueno, llego tarde...

En nuestro caso, utilizamos un par de campos extra en la tabla para comprobar los cambios.
TimeStamp y UserUpdate, que permiten saber si se ha modificado desde la última lectura y quien lo ha hecho.
Realizamos la consulta antes de actualizar para comprbar si los valores de memoria son iguales a los de la tabla.
Lectura y actualización en la misma transacción.
Creo que algo habíamos hablado aquí, aquí y aquí.

[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?

[[ArdiIIa]]

Empezado por seoane

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

Que me va a parecer mal....

Pero al márgen del refresco de la tabla y bajo esas circunstancias, no te cuesta ningún trabajo meter un evento antes de modificar y que ese evento verifique que efectivamente ese registro existe en verdad.
Desde ese evento haces un pequeño Query preguntando Select registro Where ID = al que el usuario quiere modificar
Si existe, procedes
si no existe le avisas y refrescas...

[[seoane]]

Entonces Ardilla, si te entiendo bien, sugieres que ademas de capturar el error realice una comprobacion antes de empezar para que el usuario no trabaje de mas ¿correcto?