FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
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 |
#2
|
||||
|
||||
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.
__________________
Guía de Estilo de los Foros Cita:
|
#3
|
||||
|
||||
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 |
#4
|
||||
|
||||
Hola,
Cita:
|
#5
|
||||
|
||||
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#6
|
|||
|
|||
Cita:
Por cierto hay un articulo de Bill Todd q detalla estos escenarios, buscalo en el BDN.. |
#7
|
||||
|
||||
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.
__________________
Guía de Estilo de los Foros Cita:
|
#8
|
|||
|
|||
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 |
#9
|
||||
|
||||
Cita:
¿Y si el que ha bloqueado el registro es el que se va a tomar café? Todos "parados" esperando a que acabe de desayunar... Cita:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#10
|
||||
|
||||
Cita:
Y lo que comenta Marcos no está nunca de más para efectos de auditoría. // Saludos |
#11
|
||||
|
||||
Cita:
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...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#12
|
||||
|
||||
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 |
#13
|
|||
|
|||
Cita:
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 Cita:
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) |
#14
|
||||
|
||||
Cita:
Hago Commit despues de editar, eliminar o guardar. Edito:Utilizando MDO Saludos
__________________
Van Troi De León (Not) Guía, Code vB:=Delphi-SQL, ¿Cómo? Viajar en el tiempo no es teóricamente posible, pues si lo fuera, ya estarían aqui contándonos al respecto! Última edición por vtdeleon fecha: 23-11-2006 a las 22:48:46. |
#15
|
|||
|
|||
Cita:
|
#16
|
||||
|
||||
Muchas gracias Delfino, prnto le daré una lectura.
// Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Problemas cuando varios usuarios hacen un consulta a la misma tabla | Salomon | Conexión con bases de datos | 2 | 13-06-2007 04:36:02 |
Acceso simultaneo a MySQl por internet | jjaen26 | Internet | 0 | 21-09-2006 21:07:17 |
Remote DataModulo con varios usuarios | marianoF | Providers | 0 | 30-12-2005 20:21:28 |
IB problemas por acceso simultaneo al mismo campo | Giniromero | Conexión con bases de datos | 17 | 21-04-2004 10:17:20 |
varios usuarios | maruenda | Conexión con bases de datos | 1 | 30-12-2003 17:23:15 |
|