Si se puede abrir con SQLite manager, pero ese software es solo para windows, segun recuerdo.

El asunto es que el mismo archivo de la base de datos lo puedes copiar a Mac, o a Linux, sin cambio alguno, y los puede abrir tambien. Es parte de la versatilidad que ha hecho a SQLite MUY ACEPTADO para infinidad de usos.

Mas no se necesita ninguna utilidad pues el sqlite3.exe o el equivalente en Mac o en Linux lo abre.

Bueno, preguntaba por cualquier software de ese tipo, o sea, que entonces tampoco sirve para lo que pregunta el usuario, y creo recordar que tú mismo preguntaste lo mismo en otro hilo y se te contestó que no se puede.

QUE es lo que no se puede, Casimiro?

No se puede hacer que se si se llevan la BD a otro equipo, evitar que allí puedan abrirla.

Pues que SQLite se pueda transportar a otros equipos y ahi poder abrirla se llama "portabilidad", y es uno de los atractivos de SQLite3. No es ningun defecto, al contrario, es lo que la ha hecho super popular y aceptada.

Es la base de datos mas utilizada en el planeta, y no esta sola ni es ninguna advenediza. Aunque esta donada al dominio publico, esta vigorosamente mantenida y apoyada economicamente por los grandes de la industria digital: Oracle, Apple, HP, Samsung, Adobe, Mozilla, etc.

Y es muy facil evitar que alguien la abra si la encriptas, como ya se dijo en este hilo.

Si quieres que nadie la lea, tambien puedes encriptar la particion, o el folder donde la operas. Hay varias maneras de hacerlo. Tambien hay drivers que encriptan los datos de tal manera que nadie los puede leer, solo el usuario atravez del driver, y dando su password.

Asi que realmente SI se puede evitar que alguien abra una base de datos de SQLite3 si realmente se necesita o se desea.

Es el mismo asunto que con archivos de texto, que son muy populares porque son transportables, pero nada impide que los encriptes, post-uso, o durante-uso.

Lo que ha hecho popular a sqlite es que es pequeña, sencilla de usar, cómoda de adaptar a muchos casos, que sea portable (por supuesto) y que se distribuya con una licencia de dominio público básicamente.
Se ha convertido en el típico caso de base de datos "embebida" (qué palabra tan fea) :)

Por favor, un enlace donde lo demuestre.

No es que "esté donada", es que usa ese tipo de licencia.

Vaya, en su web dice que está creada y mantenida por Richard Hipp y nadie más.
Y publica una lista de precios adicionales para poder costearse el trabajo:

Con esto no quiero decir que sea mala, es una sencilla base de datos muy cómoda y que no ocupa casi nada, es una perfecta sustituta para guardar datos en lugar de ficheros .ini y para tablas temporales, para cosas de esas, pero muchísimo más potente, evidentemente, y que puede ser usada como base de datos principal para ciertos tipos de aplicaciones.

No está pensada para entornos multiusuarios, porque aunque acepta lecturas concurrentes, sin embargo las escrituras... no. Por lo que una escritura mantiene bloqueada la base de datos para todas las conexiones y devuelve un error al acceder a ella por todos los demás usuarios.
No lo digo yo, lo dicen ellos:

Para entornos empresariales, profesionales, multiusuarios y multiprocesos reales no es válida, no porque sea mala, sino porque no está pensada para ello, son esos entornos donde trabajan postgresql, firebird, mysql, ms sql server (aunque esta última sólo para windows), etc.

A mí me gusta bastante y la veo muy útil, aunque no para sustituir a una gestión empresarial, por ejemplo.

Hola casimiro, esta donada es la palabra correcta, pues la puedes utilizar como te de la gana, sin pedir permiso ni licensia de su uso.

Ademas, no hay tal cosa como "licencia de dominio publico". Eso seria absurdo.

Tampoco es cierto lo que dices en cuanto a limites de acceso, pues SQLite3 usa caches y un control pager par permitir lo que quieres definir como concurrente.

Hay muchas personas y organizaciones que la usan empresarialmente, como te dije. Inclusive, si usas Firefox, la estas usando. Si usas una Mac la estas usando, si usas telefonos celulares inteligentes, la estas usando, si usas antivirus de McAfe, si usas Google, si usas Chrome, si usas Opera-browser, la estas usando la estas usando. No se necesita referencia para entender que tiene millones de usuarios.

Inclusive, Google contribuyo del codigo para permitir busquedas tipo Google usando SQLite3. Como ves, no solo es "una persona" la que sostiene a SQLite3.

Y aparte, no se pueden contar los usuarios totales, pues la mayoria no se reportan, ni se documentan, aun cuando la han ENCAMADO en sus dispositivos.

Aparte, SQLite3 ya es el estandard web-storage de HTML-5 aprovado por W3C Web Applications Working Group.

Tambien andas muy errado en eso de que solo Richard Hipp es el que sostiene a SQLite3.

Mira esto del sitio:
"The SQLite code base is supported by an international team of developers who work on SQLite full-time."

Y esto otro "el codigo es gratis para todo aquel que lo quiera".

Yo creo que lo referente al uso de SQLite3 no se debe de basar en lo que diga uno, que no es sino repeticion de lo que ya es informacion publica.

Al que le interese, puede libremente verificar por si mismo si le es o no adecuado.

En lo personal, si diria que como base de Desktop, es la que tiene mas ventajas, y esto no quiere decir que "desktop" sean sus limites.

PS. hay puse la palabra "encamado" ya traduciendo "embedded"..Aunque tal vez mejor palabra seria "incrustada"?

No es lo que digo yo, es lo que dice en su propia web :)

Es lo que te dije antes, si no pones un enlace a donde lo digan... no sirve de nada. Hay que contrastar la información.

Yo no lo sé, no lo digo yo, es lo que dice en su web:
Pues eso, que si no pones enlaces :)


Y repito, que no digo que sea mala, lo que digo es que sirve para lo que sirve, nada más.

enlaces:
=========================
http://www.sqlite.org/lockingv3.html

2.0 Overview

Locking and concurrency control are handled by the pager module. The pager module is responsible for making SQLite "ACID" (Atomic, Consistent, Isolated, and Durable). The pager module makes sure changes happen all at once, that either all changes occur or none of them do, that two or more processes do not try to access the database in incompatible ways at the same time, and that once changes have been written they persist until explicitly deleted. The pager also provides a memory cache of some of the contents of the disk file.

The pager is unconcerned with the details of B-Trees, text encodings, indices, and so forth. From the point of view of the pager the database consists of a single file of uniform-sized blocks. Each block is called a "page" and is usually 1024 bytes in size. The pages are numbered beginning with 1. So the first 1024 bytes of the database are called "page 1" and the second 1024 bytes are call "page 2" and so forth. All other encoding details are handled by higher layers of the library. The pager communicates with the operating system using one of several modules (Examples: os_unix.c, os_win.c) that provides a uniform abstraction for operating system services.

The pager module effectively controls access for separate threads, or separate processes, or both. Throughout this document whenever the word "process" is written you may substitute the word "thread" without changing the truth of the statement.
=====================================================

http://www.sqlite.org/mostdeployed.html
Most Widely Deployed SQL Database

We believe that there are more copies of SQLite in use around the world than any other SQL database engine, and possibly all other SQL database engines combined. We cannot be certain of this since we have no way of measuring either the number of SQLite deployments nor the number of deployments of other databases. But we believe the claim is defensible.

The belief that SQLite is the most widely deployed SQL database engine stems from its use as an embedded database. Other database engines, such as MySQL, PostgreSQL, or Oracle, are typically found one to a server. And usually a single server can serve multiple users. With SQLite, on the other hand, a single user will typically have exclusive use of multiple copies of SQLite. SQLite is used on servers, but it is also used on desktop PC, and in cellphones, and PDAs, and MP3-players, and set-top boxes.
Estimates

At the end of 2006, there were 100 million websites on the internet. [1] Let us use that number as a proxy for the number of deployed SQL database engines other than SQLite. Not every website runs an SQL database engine and not every SQL database engine runs a website. Larger websites run multiple database engines. But the vast majority of smaller websites (the long tail) share a database engine with several other websites, if they use a database engine at all. And many large SQL database installations have nothing to do with websites. So using the number of websites as a surrogate for the number of operational SQL database engines is a crude approximation, but it is the best we have so we will go with it. (Readers are encouraged to submit better estimates.)

Now let's consider where SQLite is used:

300 million copies of Mozilla Firefox.
20 million Mac computers, each of which contains multiple copies of SQLite
20 million websites run PHP which has SQLite built in. [3] We have no way of estimating what fraction of those sites actively use SQLite, but we think it is a significant fraction.
450 million registered Skype users.
20 million Symbian smartphones shipped in Q3 2007 [5] Newer versions of the SymbianOS have SQLite built in. It is unclear exactly how many Symbian phones actually contain SQLite, so we will use a single quarter's sales as a lower bound.
10 million Solaris 10 installations, all of which require SQLite in order to boot.
Millions and millions of copies of McAfee anti-virus software all use SQLite internally.
Millions of iPhones use SQLite
Millions and millions of other cellphones from manufactures other than Symbian and Apple use SQLite. This has not been publicly acknowledged by the manufactures but it is known to the SQLite developers.
There are perhaps millions of additional deployments of SQLite that the SQLite developers do not know about.

By these estimates, we see at least 500 million SQLite deployments and about 100 million deployments of other SQL database engines. These estimates are obviously very rough and may be off significantly. But there is a wide margin. So the SQLite developers think it is likely that SQLite is the most widely deployed SQL database engine in the world.

Si una base de datos tiene futuro es SQlite y conviene adentrarse en ellas, es SQlite3.

Y no es lo que yo digo, tampoco, Don Casimiro.

Pues eso, amigo ElMug, firefox lo usa para mantener enlaces, historial, etc.
Skype lo usa para tus contactos, guardar historial, etc.
McAfee lo usa para su base de virus, logs, etc.
Lo dicho, lo usan para lo que está básicamente diseñado sqlite, es lo que he dicho antes, prácticamente todos son monousuarios.

¡uy!, 'Don', eso me hace muy viejo :D

Pues haciendo a un lado lo venerable de la edad, y por un rato el nombre de CASImiro, mirando completo, has de ver que tu aseveracion de que SQLite esta "diseñada para uso monousuario" no es correcta, pues si fuera como tu dices no tendria caso alguno de que tuviera su sofisticado y eficiente manejo de locks. Que alguien haya dicho, piense, o desee que SQLite este diseñado para uso monusuario, es algo muy aparte de la verdad.

Si lo que quieres decir es que las bases con motor tipo servidor son en la mayoria de los casos impracticas para uso monousuario, no lo cuestionaria.

Ahora, que SQlite3 no esta diseñada para transacciones cuantiosas y tupirle muchos usuarios que graben data con gran frecuencia, de gran volumen, o de transacciones de muchas operaciones, eso lo dice muy claramente la pagina de SQLite, pero por ningun lado dice que SQLite "esta diseñada", o se limite a monousuario.

Es que una cosa lleva a la otra :)
Como puedes ver, el uso mayoritario (de tu lista) es monousuario. Que permite múltiples usuarios leyendo, de acuerdo. Pero no escribiendo, por lo tanto, si quieres lo definimos como: multiusuario leyendo y monousuario escribiendo :D

Hola
me parece que seria muy bueno dividir este hilo:
1- BD SQLite protegida por Usuario y Contraseña (pregunta original)
2- Es Sqlite una base de datos multiusuario, escritura ( si/no, por que ? :confused:).
Os voy a enviar a leer la guia de estilo a ambos.......:D:D:D
Saludos
PD: yo se que access es mejor y no lo discuten...:D:D;)

Tienes razón, Caral :o
No sé si se puede dividir el hilo, me parece que es demasiado complicado.

Resumiendo:
En principio, si te la llevas a otro equipo, allí puedes abrirla, así que no se puede proteger "normalmente", quizás pagando se pueda.
Aunque puede ser leida por varios usuarios, si se intenta escribir por más de uno entonces no se puede.
Para mí eso no es una BD multiusuario en el concepto "normal".

Por supuesto, todos lo sabemos ;)

Cita:
Empezado por Caral
PD: yo se que access es mejor y no lo discuten...:D:D;)

Por supuesto, todos lo sabemos ;)
===============================

Los de Saturno no estamos de acuerdo con los terricolas, especialmente cuando no saben que Access no es una base de datos, sino un administrador de bases de datos, que por default usa la base de datos llamada Jet-Engine. Y hay muchos terricolas que moran en esa confusion.

Por eso casi no visitamos el planeta.:cool:

Hola
Por lo menos se logro cambiar de tema.....:D:D;)
Saludos

¿Jet-Engine?, creía que se llamaba jet4 :confused:

¿A qué te refieres con pagando? :confused:

Esto es discutible. Con todo y su antigüedad y sus limitaciones, Paradox, por ejemplo, bien puede decirse que es multiusuario. Puedes tener un sistema con una base Paradox y múltiples usuarios simultáneos. Claro que tienes que establecer bloqueos y fijarte si no hay uno al momento de escribir un dato, pero de que puede funcionar, puede.

Por otro lado, en un gestor `de verdad`, tampoco pueden, si nos ponemos muy estrictos, escribir al mismo tiempo varios usuarios. Bueno, de que pueden, pueden, pero, si vendiste el último par de calcetines, ¿te quedas así tan campante sin saber si otro vendedor ya lo hizo al mismo tiempo que tú? O, si modificaste los últimos lineamientos de ClubDelphi, ¿te quedas tranquilo sin pensar que a lo mejor yo también los modifiqué al mismo tiempo? :p

// Saludos

A que pagando puedes añadir estas extensiones:
Lo digo por esto:

Pues sí. Sé a lo que te referías. Pero lo que yo digo es que no necesariamente eso le quita el adjetivo multiusuario y que aún en los gestores que no te marcan un error cuando hay dos escrituras simultáneas, tienes que hacer verificaciones, o sea que no es que te den todo hecho para la simutaneidad.

// Saludos

Aca en Saturo todo es al revez: hasta el menos sabio sabe que DOS cosas no pueden estar al mismo tiempo en un solo lugar, que todas la bases de datos, hasta las mas robustas, usan sistemas de locks y esperas.

En el planeta tierra, ni se diga, es como tumban los sitios ahi: con un tumulto de accesos.

Y aunque los terricolas no lo sepan, o por discutir, se les olvida que "simultaneo" no quiere decir realmente "simultaneo", sino bastante rapido como para que PAREZCA "simultaneo".

Las bases de datos tipo servidor usan muchos archivos, para "cachar" informacion mientras se libera el record o bloque donde tiene que hacerse la grabacion final.

Muchas de sus base de datos se bloquean cuando no son de las mas robustas, y viven las esperas requeridas.

SQLite es igual, o similar, bloquea por milisegundos, en transacciones tipicas, y usa archivos temporales escritos a disco o a memoria. Solo que es para uso LEVE en ese asunto. Y es por eso que se llama a si misma "lite", que quiere decir "ligera".

En cuanto a encriptar a SQLite, hay como en casi todo hoy en dia, gratuito y a costo. Cual sirva o no sirva, no viene al caso sin tener como base la experiencia del haberlo verificado.

Pero, en Saturno como el el planeta Tierra, la mayoria de las bases de datos no usan encriptamiento y toda data que no este encriptada, se puede leer.

Alquien de este foro usa encriptacion en sus bases de datos?

No, no es exactamente así.

Explica, tu, como es, casimiro.

Amigos del foro,

Les platico esto que les pueda ser de interes, en cuanto a el tema tratado en este hilo:

Hice una prueba usando una aplciacion que desarrolle , que puede mandar a una base de datos SQLite3 un conjunto de renglones para cargar le bastante data en una transaccion.

La data es real (la consegui del web) consiste de cargar 239 paises, o sea una tabla con 15 columnas y 239 renglones. Las columnas son codigo de pais,nombre de pais, continente, region, superficie, año de independencia, poblacion, vida promedio de habitantes, GNP, gnpANTERIOR, nombre local, tipo de gobierno, presidente o cabeza de estado, capital, codigo1, Codigo2.

En total son 3,585 datos a cargar a cada tabla.

Corri 2 instancias de la misma aplicacion, y a cada una la prepare para que mandara la misma data, CREANDO cada una tabla identica, pero con nombres Pais1 y la otra Pais2, a la misma base de datos, que ya cada instancia tenia abierta. Cada transaccion crea su tabla y la carga de datos.

Puse los botones de mando de cada aplicacion pegaditos (usando always on top) a manera de que pude hacer click una aplicacion y la otra al instante.

No recibi ningun mensaje de error, y casi ni lo creia, cuando vi que INSTANTANEAMENTE, se crearon en la MISMA base de datos DOS tablas, Pais1 y Pais2, identicas, cada una con 3585 datso reales cada tabla, que son 7,170 datos en total, contenidos en 239 renglones mult. por 2 = 478 renglones que cargo sin chistar.

Esto debio de haber ocurrido en milisegundos, pues hasta parecio que no habia habido respuesta a los dos clicks practicamente simultaneos, mas rapido no podria haber picado los botones uno tras otro, pues estaban pegaditos.

Si esto no es acceso concurrente, alguien tendria que tener base para negarlo.

Ahora, comparen lo que se tardarian operadores terricolas tecleando esta informacion y mandandola para grabarla, a la base de datos. Tal vez unos cuatro capturistas tardarian un par de dias en hacerlo y no veo como SQLite no tuviese la capacidad de manejarlos a todos simultaneamente.

Les aviso que soy pianista y puedo picar botones con mucha rapidez.

De todas maneras, les recuerdo que nunca dije, ni diria, que SQlite sea mejor que otra, pero que es multiconcurrente y mltiusuario, con sus limitaciones, claro, sostengo que SI lo es.

Bueno, hasta la vista.

No, eso no es acceso concurrente.

Claramente, esto no es un acceso concurrente. Tendrías que haber insertado en la misma tabla para poder hablar de concurrencia y aún así, si no se repite la llave primaria, tampoco estarías hablando de concurrencia.

Yo entiendo tu defensa de SQLite, y también creo que el concepto de concurrencia es discutible, pero tampoco hay que exagerar y hacer ver a SQLite como uno de los grandes no Lite.

// Saludos

Amigo ElMug, si quieres hagamos una prueba, a ver si sqlite la pasa con éxito:

En una tabla donde tengas ya registros, o creas una nueva, no importa que sea simple, ejemplo:

Código SQL [-]
create table tbPrueba (
  id integer not null,
  nombre varchar(64),
  telefono varchar(9),
  importe float,
  primary key (id)
)

En esa tabla inserta 100, 500, 1000 registros, los que quieras.
El 'id' será la clave primaria, así que introduce 1,2,3,4,5,... 999,1000
El resto de campos, lo que te parezca, cualquier dato aleatorio.

Ahora crea un programita sencillo en plan rápido que haga esto:

Código Delphi [-]
var
  iX , iCodigo : integer;  
begin  
  query.close;
  query.sql.text := 'update tbPruebas set nombre= :nombre, importe= :importe where id= :id';

  for iX:=1 to 100000 do  // cien mil actualizaciones, para que dé tiempo probar.
  begin
    iCodigo := random(1000);  // esto devuelve un número aleatorio entre 1 y 1000 (o los registros que existan en la tabla)
    query.close;
    query.params[0].asstring := inttostr(iCodigo);
    query.params[1].asfloat := iCodigo;
    query.params[2].asinteger := iCodigo;
    query.execsql;
  end;
end;

Pones 1 botón y ejecutas. No debe fallar.
Ahora abres otra instancia del programita, vamos a simular 2 usuarios trabajando.
Ejecutas y pruebas. Si no falla, puede ser que no falle si no coinciden en actualizar el mismo registro.
Ahora abres otra instancia del programita, ahora serán 3 usuarios trabajando.
Y así hasta que te aburras. A ver qué ocurre.

Cuantos más registros tengas, menos posibilidades de que toquen el mismo registro al mismo tiempo.
Cuantos menos registros tengas, más posibilidades de que seleccionen el mismo.
Cuantos más usuarios al mismo tiempo, más posibilidades de que seleccionen el mismo.

Es sólo algo didáctico, por probar.

p.d. He puesto más o menos como debe ser el código, no tengo ningún delphi/lazarus para probar.

Oye Casimiro, ¿y qué pasa en Firebird si hago esta misma prueba que propones? ¿Qué pasa si dos usuarios tocan el mismo registro al mismo tiempo?

// Saludos

No, no voy a hacer esa prueba que dices Casimiro, porque ya debes de saber que SQLite bloquea toda la base de datos por milisegundos requeridos para grabar.

La prueba que describo se debe de entender asi. Pero lo bello del SQLite3 es que es TAN RAPIDA que el tipico usuario en una aplicacion mediana, con datos tipicos de facturas, inventarios, altas, etc., no tiene problema en brindar multiusuario y escritos concurrentes.

Cada aplicacion es "su propia maquinita" y se comunican unas a otras atravez de archivos temporales.

Ahora, esto que les mencione brevemente, es tambien MUY IMPORTANTE para quien desea (ahi si) que haya mucha mas concurrencia permitida, es que SQLite puede conectarse con hasta 10 bases de datos, cada base de datos puede tenter un numero enorme de tablas, y cada tabla un numero enorme tambien de campos. Todos esos "enormes" son miles.

Cuando conecta una aplicacion a varias bases de datos, TODAS las bases y sus tablas son accesibles a comandos SQL, como si fuera una sola base de datos.

Entonces pues, ahi Usuario1 grabando datos en Base de datos 1, y Usuario 2 grabando en base de datos 2, no ven ni uno de los dos NINGUN lock.

Quiere decir que para un negocio tipico, en el que una sola base de datos no fuera adecuada, se pueden repartir el archivo de escritos mas frecuentes en su propia basededatos, y los menos frecuentes en otra. Si hay mucho trafico, para otro tipo de archivo, se usa OTRA mas, base de datos.

Todas esas bases de datos son relacionales, conforman a integridad referencial. Inclusive, tiene SQlite el sistema de "triggers" que son un equivalente a "stored procedures" que tambien se pueden considerar en cuanto a rendimiento.

Lo que dije antes, no he logrado que se corrompa ni una sola de las bases de datos, a pesar que les he dado bastante duro.

Lo que todos ustedes saben es que hay muchas tecnicas posibles para hacer las cosas mejor, o superar limitaciones, y con SQLite eso no es la excepcion.

Pongo esto por lo que a alguien le pueda interesar o servir. Pero no hay nada mejor que cada quien buscar lo mas aproximado a lo cierto.

Hasta luego.

P.S. No vayan a salir conque repartir archivos es un truco o es algo inferior, pues les recuerdo que de hecho, ASI trabajan muchas bases de datos: usan un archivo para cada tabla, y ESO en gran parte es lo que les da mas concurrencia. Y esto es lo mismo aun en las bases de datos mas poderosas. Postgres, por ejemplo, asi lo hace. Claro que tienen mecanismos mucho mas avanzados para repartir el trabajo y la data.

Firebird tiene una arquitectura "multigeneracional" y guarda distintas "versiones" del registro que está siendo consultado, editado, etc. y que según el nvel de aislamiento escogido para las transacciones trabajarán de distinta forma.
Si un usuario está editando un registro y otro usuario entra a editar el mismo registro, el último no ve los cambios que está haciendo el primero (mientras el primero no confirme los cambios), básicamente el último en escribir es lo que se mantiene
En la práctica, usando transacciones con los parámetros:
read_committed
rec_version
nowait
Es prácticamente imposible que sucedan "deadlocks", es más, yo jamás los he visto.

Mejor pego una explicación más técnica, no sé qué tal es la traducción:

Así que sqlite permite miles de campos, eso está bien.
Amigo, no sé de dónde eres, pero por aquí decimos: "tú sigue en tus mundos de yupi" :)

Aquí quería yo llegar :)

Mi punto es: si no implementas algún tipo de control, por muy multigeneracional que sea, el último en guardar los cambios va a machacar los cambios de los demás. La aplicación puede optar por un bloqueo optimista y, por lo menos, avisar al último usuario que alguien ya hizo cambios.

En estos términos, estamos igual que con motores no concurrentes: hay que tener un control sobre qué hacer cuando hay accesos simultáneos a la misma información.

// Saludos

En ese aspecto es configurable para trabajar de la forma más adecuada a lo que necesite cada uno.

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.

Aqui para los que dicen que SQLite3 no es multiconcurrente, acabo de hacer otra prueba, aun mas extensa.

1. Misma base de datos anterior que contiene dos tablas: Pais y Pais1.
La tabla Pais ya existe, con la data original de todos los paises (ya explicado antes) y es unica que se usa en esta prueba. La tabla Pais ya contenia 239 renglones, uno para cada pais.

2. Una aplicacion que manda los comandos que se le carguen, se abre dos veces, en dos instancias: App1 y App2

3. Se le carga a ambas el MISMO set de commandos SQL. Este set carga los 239 paises del planeta, con sus respectivas estadisticas, ya descritas.

4. Esta es una tira tipica de las 239 tiras del set:
INSERT INTO "country" VALUES('GUM','Guam','Oceania','Micronesia',549,NULL,168000,77.8,1197,1136,'Guam','US Territory','George W. Bush',921,'GU');
I
5. Amartillo las dos aplicaciones de tal manera que los botones de App1 y App2 de mando estan a un centimetro de separadas y el tiempo en presionar el boton de mando en App1 y App2 es minimo.

6. Como ahora no se crean tablas, y la tabla permite cargar duplicaciones, nada me impidio que me diera vuelo en presionar App1 y App2 alternandolos MUCHAS VECES y SIN LIMITE ALGUNO que el de mi rapidez y en unos cuantos ciclos la tabla Pais tiene ya 30,000 paises apx. Ni una sola de las veces rechino ni salio mensaje que me impida repetir esto hasta el cansancio.

No conte los cliks que di, pero dividiendo me resultan 125 transacciones A LA MISMA TABLA Pais que SQLite3 recibio correctamente, sin chistar.

Como ven, a SQLite no le importa a cual tabla le envien el grabado, siempre y cuando la data que se le mande sea correcta.

P.S. Me tarda mas escribir este mensaje que hacer las pruebas. SQLite3 todavia me esta esperando para que les siga picando el boton a App1 y App2, pues todavia las tengo preparadas y les puedo seguir picando los botones. Mas la verdad es que no le veo el caso. Para mi esto es concurrente y multiusuario. Que haya mas capacidad que esto, no lo niego.

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.

// Saludos

Bueno, lo multigeneracional es precisamente para eso, para NO bloquear los escritos con read-locks (candados puestos al leer). Y el "aviso" es que si los que estan leyendo tratan de escribir, entonces se les rechaza su transaccion, porque el motor sabe que la version en que quieren basar su grabacion es vieja. Al menos eso es lo que hace Postgres.

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

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 ;)

Pues eso lo hace SQLite3 con muchisima mas facilidad:

Usuario-1 hace un cambiecillo a tira-a y Usuario-2 hace otro un cambio a tira-1 se hacen los DOS cambios, uno tras otro. Mientras la data sea valida, ambos cambios se aplican. Si la data de uno de los dos usuarios no califica, la transaccion se rechaza.

Por ejemplo, si no se permiten duplicados de registro, y el usuario-2 quiere duplicar, pues se le rechaza.

Ninguna base de datos puede cambiar un registro exactamente al mismo tiempo.

Yo creo que mal-entiendes algo, Casimiro.

Cual es el problema?

¿Duplicados de registro?, ¿a qué te refieres con eso?

Sí, con el sistema multigeneracional de firebird, van creándose "versiones" del mismo registro, al mismo tiempo.
Aunque si te refieres "exactamente al mismo tiempo".... hombre, eso es prácticamente 'casi' imposible, si varía unas millonesímas de segundos, ya no es "exactamente al mismo tiempo" :)

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