Cita:
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...:D:D |
Cita:
|
Cita:
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... |
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? :confused:
|
Por cierto, ya sería mucha casualidad que el servicio borrara el registro que el usuario está modificando, no ?
|
Cita:
Que te asegures que el registro a modificar, existe en la BD |
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. |
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 |
Hola
Pregunto IB, no permite transacciones? En ese orden. Solo pregunto, porque cuando se hacen este tipo de cosas, se pueden perder datos, me parece. Saludos |
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.
|
Cita:
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í. |
Cita:
El problema mas grave era que el servicio borraba registros, y el usuario no lo sabia e intentaba modificarlos. Así que ahora antes de modificar nada, compruebo que el registro sigue ahí (de hecho actualizo los datos), y parece que con eso es suficiente por ahora. Muchas gracias |
La franja horaria es GMT +2. Ahora son las 13:44:12. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi