BD SQLite protegida por Usuario y Contraseña

[roman]

Empezado por Casimiro Notevi

Otra cosa distinta es que si yo abro para editar, y me voy rápido al baño. Tú mientras tanto llegas y modificas el mismo registro que yo he dejado editando. ¿Qué hacer?, ¿avisarte de que lo está editando otro usuario y no dejarte hacer nada?, ¿dejarte editarlo?, creo que lo correcto es lo último.
Luego vuelvo yo y le digo "guardar", ¿debería dejarme?, ¿debería decirme que otro usuario ya ha modificado mi registro?.

Claro, este es el problema. El punto es que tienes que seguir una estrategia que no pasa por simplemente guardar lo que hizo el último, sobre todo si ese último no necesariamente es el primero en abrir el registro. Y, aunque el cliente configure a su gusto, como dices, tu software tiene que saber qué hacer con la respuesta.

Bueno, en un sistema de bloqueos resulta lo mismo. El software tiene que decidir qué hacer si quiere abrir un registro bloqueado. Aunque las opciones son menos.

Ahora bien, si esto sucede muy pocas veces en la vida real, con mayor razón bastaría usar bloqueos. Incluso podríamos usar bases del tipo NoSQL que ni transacciones tienen pero que son muy cómodas de usar.

Creo que por el contrario, esto sucede con mucha frecuencia, aunque no el caso que describes y por ello la preocupación de que el gestor sea ACID. No se trata, como el ejemplo que pones, de una mala organización de l compañía en la que dos empleados editan los mismos datos. Si tienes que manejar un stock, necesariamente va a haber varios puestos accediendo a las existencias del mismo producto.

// Saludos