|
1. la solucion del campo timestamp, resuelve el problema.
2. Tambien como alguien comenta con interbase me lanza una exception al del cafe (estoy de acuerdo, a la picota con el)
pero el que modifica sobre los datos antiguos (el A del ejemplo) se entera de que sus cambios no se puden guardar despues de haberlos escritos. Es decir
1. el cliente A guarda tras media hora en la maquina del cafe
2. el programa comprueba el campo timestamp que hay en la tabla, de forma que sabemos que el registro que ha modificado y esta intentando
guardar ha "caducado". (Interbase ya hace este trabajo con nosotros)
3. Si ha caducando le mandamos un mensaje "Registro caducado". Cancelamos los cambio y refrescamos el registro
4. El cliente A. Ha escrito algo en un registro, que perderá. Aunque lo mas probable. ¿No hay manera de hacer esto de antes de permitir modificar?
Alguien apunta a bloqueos pesimistas. Con Interbase/firebird y utilizando IBX. Hacímos una actualización tonta por ejemplo
updata articulo
set idart=idart
where idart=idart
mientrasn no hagamos un commit, firebird bloquea el registro. Es una forma de hacer un bloqueo pesimista. Con este "truco" desde que un segundo cliente intenta modificar un registro que alguien ya esta modificando, le sale un error, de que otro usuario ya esta modificando el registro u que lo intente mas tarde
con DBX se puede hacer algo parecido (Pregunto), es decir:
salu2
|