Saber si está bloqueado un registro

Hola,

Este problema se da muy a menudo, yo aconsejo una estrategia de
"refresco" donde la aplicacion antes de modificar un registro comprueba
si los datos han cambiado desde que fueron leidos.

Un primara solucion es añadir un campo datetime llamado
UltimaModificacion. Ahora bien, puede que sepas cuando el registro ha
cambiado, pero como gestionar que debe hacer la aplicacion cuando esto
ocurre puede ser laborioso.

Otra solucion es establecer un flag en el registro, el usuario tiene
que indicar que quiere editar un registro antes de hacer ninguna
modificacion, cuando esto ocurre el sistema actualiza el flag, si otro
usuario intenta editar el registro el sistema le indica que hay alguien
mas en el sistema editando el registro. Cuando se confirma o cancela el
proceso de ediccion entonces el flag vuelve a su estado normal.

Esta última solución es la que he visto mas a menudo.

No es un tema facíl de solucionar. Microsoft tiende a solucionar este
problema dejando abierto el recordset entre el cliente y el servidor,
puedes utilizar recordsets que se actualizan automaticamente. Pero como
todo, tiene muchas desventajas y la verdad que en aplicaciones de
tamaño medio a grande no lo recomiendo.

Saludos

Gracias por la solución, pero no nos sirve.
Si hacemos el update para hacer la marca como indicas, tenemos que hacer el
COMMIT y no nos interesa hacerlo en ese momento ( el usuario puede hacer
varios proceso a la vez y no nos interesa que se grabe sin el consentimiento
del usuario ).
Además, si no hacemos el COMMIT, osea que dejamos el UPDATE solo para hacer
la marca, hasta que no se haga ROLLBACK o COMMIT, el registro queda
bloqueado.
Entonces si otro usuario quiere hacer una SELECT en que este registro
aparezca, dejará la SELECT esperando a que el usuario termine. y no
puede ser, por eso pedía que si existía alguna tabla en que se pudiese
determinar con antelación si un registro en concreto está bloqueado.

Gracias nuevamente por la respuesta.

"Enrique Albert" escribió en el mensaje
news:
Hola,

Este problema se da muy a menudo, yo aconsejo una estrategia de
"refresco" donde la aplicacion antes de modificar un registro comprueba
si los datos han cambiado desde que fueron leidos.

Un primara solucion es añadir un campo datetime llamado
UltimaModificacion. Ahora bien, puede que sepas cuando el registro ha
cambiado, pero como gestionar que debe hacer la aplicacion cuando esto
ocurre puede ser laborioso.

Otra solucion es establecer un flag en el registro, el usuario tiene
que indicar que quiere editar un registro antes de hacer ninguna
modificacion, cuando esto ocurre el sistema actualiza el flag, si otro
usuario intenta editar el registro el sistema le indica que hay alguien
mas en el sistema editando el registro. Cuando se confirma o cancela el
proceso de ediccion entonces el flag vuelve a su estado normal.

Esta última solución es la que he visto mas a menudo.

No es un tema facíl de solucionar. Microsoft tiende a solucionar este
problema dejando abierto el recordset entre el cliente y el servidor,
puedes utilizar recordsets que se actualizan automaticamente. Pero como
todo, tiene muchas desventajas y la verdad que en aplicaciones de
tamaño medio a grande no lo recomiendo.

Saludos

Me parece que no me he explicado bien. La solución que propuse no
utiliza la transacción como indicas.

Cada vez que un usuario inicia un proceso de edición tienes que
ejecutar un UPDATE para actualizar la marca, no bloquees el registro.

Cuando este proceso finaliza el usuario es el único que puede
modificar el registro, cuando termine entonces otro UPDATE modifica los
datos y "limpia" la marca, dejando a otros usuarios modificar el
registro siguiendo el mismo proceso.

Es un diseño similar a un MUTEX pero en una tabla y muy simple.

El problema es examinar si la aplicacion puede modificarse sin
demasiados cambios.

Saludos

Creo que ya lo he entendido probaremos a ver que tal vá.

Gracias nuevamente.

"Enrique Albert" escribió en el mensaje
news:
Me parece que no me he explicado bien. La solución que propuse no
utiliza la transacción como indicas.

Cada vez que un usuario inicia un proceso de edición tienes que
ejecutar un UPDATE para actualizar la marca, no bloquees el registro.

Cuando este proceso finaliza el usuario es el único que puede
modificar el registro, cuando termine entonces otro UPDATE modifica los
datos y "limpia" la marca, dejando a otros usuarios modificar el
registro siguiendo el mismo proceso.

Es un diseño similar a un MUTEX pero en una tabla y muy simple.

El problema es examinar si la aplicacion puede modificarse sin
demasiados cambios.

Saludos