BD SQLite protegida por Usuario y Contraseña

[Casimiro Noteví]

Empezado por ElMug

Acceso multiconcurrente es que mas de un usuario pueda grabar en una base de datos, sin importar los mecanismos usados, y esto lo hace SQLite3 usando su Modulo Pager.
SQLite3 tambien usa dos copias de las transacciones y las usa para el roll-back y para controlar el uso simultaneo de escritos a una misma tabla.

Hablamos de editar un mismo registro, no de insertar nuevos, ahí no hay problema.

Empezado por roman

Je, je. Estás escurriendo el bulto o yéndote por la tangente. El texto que citas no resuelve el problema que menciono. Cada usuario podrá tener una vista muy coherente de los datos, pero eso no quita que uno machaca los datos del otro.

Evidentemente, si yo guardo algo y tú guardas después, ¿qué hacer?, pues mantener el último, eso es lo lógico, ¿no?.
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?.

Cada una de esas preguntas admite varias posibilidades, y para ello se puede configurar a gusto del consumidor: read_commited, nowait, snapshot, etc. son parámetros para que firebird "responda" de una manera u otra, dependiendo de lo que queramos.
Habitualmente, siempre, he preferido que se guarde lo que haga el último que guarda. ¿Para qué bloquear?, además de que en la vida real no suele haber problema por eso, realmente nunca he tenido un problema por eso, pongamos un ejemplo simple:
Tenemos un cliente: codigo: 1000, nombre: empresapaco, DescuentoHabitual: 10 %
El cliente es muy bueno y el jefe dice: "al cliente empresapaco le subimos el descuento habitual al 12%"
Si nuestra empresa es un caos de organización, tenemos a todos los trabajadores de la oficina abriendo la ficha del cliente y modificando su descuento habitual. Todos sobreescriben los datos de los demás, ningún problema.
Pero si hay uno un poco sordo y entendió 14 en lugar de 12, y es el último en grabar... se quedará el 14%
¿Es un fallo de firebird, postgresql, mysql, etc.?, evidentemente, no.

En la vida real creo que es difícil encontrarse problemas con una base de datos por cosas de ese tipo, incluido sqlite