acceso simultaneo varios usuarios Tabla interbase
 

Hola, estoy utilizando Firebird, con D 2006. Accedo a la BD con IBExpress.

El caso es que estoy realizando una aplicacion que va a funcionar en red, por tanto varios usuarios va a modificar datos al mismo tiempo (Naturalmente se puede dar el caso de que dos clientes modifiquen el mismo registro al mismo tiempo).

Vamos a suponer que hay dos clientes accediendo a la misma tabla, mismo registro, vamos a llamarlos A y B. SUpongamos que:

1. El cliente A edita un registro de la tabla
2. El cliente B edita el mismo registro que el A
3. El Cliente A se despista y se va a tomar cafe
4. El cliente B guarda sus cambios
5. El cliente A vuelve de tomar cafe modifica su registro (recordar que el registro es el mismo que el que ya ha modificado el B, naturalmente el registro que modifica el A es anterior a la modificacion que realizo el cliente B)
6. El cliente A guarda. Los cambios que hizo al registro el cliente B han desaparecido

¿Que estrategias se os ocurren para evitar esto?


salu2

No olvides que el ejemplo que pones es una característica de las bases de datos cliente/servidor. Tambíen puede ocurrir:

Cliente A.- Efectua un cambio en un registro y lo guarda.
Cliente B.- Efectua un cambio en el mismo registro 10 minutos más tarde y lo guarda.

Si al final termina con una incoherencia en los datos es porque alguno de los dos no ha obrado bien, podemos tener un registro de cambios efectuados y saber quien fue el último que modificó ese registro.

Un Saludo.

No entiendo muy bien lo que quieres decir Marcos. El caso que planteas no es achacable al sistema sino a la impericia de un usuario. Pero en el caso planteado, el lapso transcurrido como puede ser de diez minutos puede ser de unos segundos o menos, y el sistema sí es el responsable de controlarlo ¿no?

Si no mal entiendo, puede optar por un bloqueo pesimista o uno optimista. En el primero, se bloquea el registro y a fregarse todos los demás mientras el señorito no vuelva de tomarse el café. En el segundo, se toma la hora en que se inicia la edición y se graba en la tabla en un campo ad hoc para ello. Al momento de guardar se mira primero si la hora en la tabla coincide con la que tenemos nosotros. Si no es así es que alguien ya ha hecho otros cambios y tendremos que decidir si machacarlos o descartar los nuestros.

// Saludos

Hola,

Eso, eso; y al culpable le ponemos en la picota y le rapamos al cero, para escarmiento del personal presente. :eek: :rolleyes: :p :) :D

Hace unos días estuvimos halando aquí del mismo tema; Está explicado el sistema que he utilizado yo alguna vez, mediante un campo de TimeStamp; Supongo que hay más.

Esto no ocurre con Firebird, el sistema avisara al usuario A q ha cambiado el registro desde su ultima visita al mismo y si quiere ver las modificaciones y cargar la ultima version (del B).

Por cierto hay un articulo de Bill Todd q detalla estos escenarios, buscalo en el BDN..

Lo que digo es muy frecuente sobre todo en programas de facturación, el empresario quiere saber por ejemplo quien hizo la factura/Pedido/Albarán y quien fue el último en modificarla, con un par de campos está arreglado, son campos que nunca aparecen en pantalla pero que el administrador entrando con su clave si que puede ver:

Autor:F20000/06 23/11/06 12:10:22 Puesto1 Pepeperez
Modif:24/11/06 12:10:00 Puesto3 Amaliasaleconfritas

Un Saludo.

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

Para un Cliente/Servidor me parece muy restrictivo.
¿Y si el que ha bloqueado el registro es el que se va a tomar café? Todos "parados" esperando a que acabe de desayunar...:D

¿Significa eso que vas a tener la transacción abierta todo el tiempo que dura la edición del registro?

No es muy distinto de lo que he dicho arriba ¿no?

Y lo que comenta Marcos no está nunca de más para efectos de auditoría.

// Saludos

Sí, sí, cierto Román.
O no lo leí o lo leí mal, pero es lo mismo, pero es lo mismo, pero es lo mismo, pero es lo mismo...
Últimamente me repito un poco... :D

Ahora bien, me gustaría aclararme porque no conozco ib/fb. De acuerdo a lo que menciona Delfino, ¿he de entender que FB ya maneja por nosotros los bloqueos optimistas?

// Saludos

bueno si estas programando para funcionarios les pones un timer y a x tiempo sin hacer modificaciones, liberas el registro y listo (bueno se me ocurre).

Restrictivo, pues no se, todos los clientes pueden acceder a todos los registros, excepto aquellos que esten bloqueados por los demas que tan solo los podran leer. Son bloqueos pesimistas, en algunos casos puede ser util. En otros una pesadilla

con FB si te haces una pequeña aplicacion Delphi+FB+DBX que acceda a una tabla.

1. Ejecutas la aplicacion por primera vez (llamemosla A)
2 .Vuelve a ejecutarla por segunda vez (llamemoslo B)
3. si en A haces una modificacion y la guardas (el registro que esta en B queda obsoleto)
5. Te vas a B y haces una modificacion
6. Guardas, y debes obtener un error que dice algo asi como que el registro ha sido modificado por otro usuario. No te deja meter la pata, Al menos a mi me funciona asi (esto me pasa con FB 1.5)

Hice una pruebita con una aplicación y no me arrojó nada. Guardo el ultimo.

Hago Commit despues de editar, eliminar o guardar.

Edito:Utilizando MDO

Saludos

Ay va un articulo detallado del comportamiento de IB/FB con el acceso concurrente..

Muchas gracias Delfino, prnto le daré una lectura.

// Saludos