SQLite3 aplicaciones Delphi en misma base de datos?

[roman]

A ver, sinceramente creo que aquí hay un mar de confusiones.

La documentación de SQLite (no la vuelvo a citar pues ya se ha hecho en varias ocasiones en el hilo) claramente indica que SQLite es concurrente y que no saben de ningún otro sistema encajado que maneje tanta concurrencia como SQLite. Al mismo tiempo, también establece que tiene sus limitaciones y que no puede compararse con gestores mayores (de los cuales, por cierto, Firebird no es, ni con mucho el único y no necesariamente es el mejor).

Que la concurrencia que menciona la documentación de SQLite sea o no una concurrencia real, es un asunto cuestionable, claramente, pero el sujeto de dicha objeción sería, en todo caso, el desarrollador de SQLite y no un forista que pregunta acerca de ello.

Quizá me equivoque, desde luego, pero en mi opinión, el forista dejó en claro desde un principio que era consciente de las limitaciones y la pregunta era si con delphi podía abrirse una misma base de datos con dos aplicaciones, que no es lo mismo que preguntar si SQLite es o no concurrente.

En una rápida prueba usando Delphi 7 y ZEOS veo que sí, que dos aplicaciones delphi pueden abrir la misma base de datos al mismo tiempo.

// Saludos

[Casimiro Noteví]

Entonces "alguien" no ha entendido la pregunta porque eso se suponía que se puede hacer y que no hace falta ningún componente especial para hacerlo, valen todos.

[roman]

El punto es que, al menos según lo que reporta el forista, en Lázarus no se puede. De ahí que pregunte si en delphi sí se puede.

// Saludos

[[AzidRain]]

¿No bastaba la respuesta de Roman, o un simple "En Delphi si se puede asi y así" o "No se puede por esto y esto"? Obviamente cualquiera de las 2 respuestas debidamente comprobables.

[ElMug]

Empezado por roman

A ver, sinceramente creo que aquí hay un mar de confusiones.

La documentación de SQLite (no la vuelvo a citar pues ya se ha hecho en varias ocasiones en el hilo) claramente indica que SQLite es concurrente y que no saben de ningún otro sistema encajado que maneje tanta concurrencia como SQLite. Al mismo tiempo, también establece que tiene sus limitaciones y que no puede compararse con gestores mayores (de los cuales, por cierto, Firebird no es, ni con mucho el único y no necesariamente es el mejor).

Que la concurrencia que menciona la documentación de SQLite sea o no una concurrencia real, es un asunto cuestionable, claramente, pero el sujeto de dicha objeción sería, en todo caso, el desarrollador de SQLite y no un forista que pregunta acerca de ello.

Quizá me equivoque, desde luego, pero en mi opinión, el forista dejó en claro desde un principio que era consciente de las limitaciones y la pregunta era si con delphi podía abrirse una misma base de datos con dos aplicaciones, que no es lo mismo que preguntar si SQLite es o no concurrente.

En una rápida prueba usando Delphi 7 y ZEOS veo que sí, que dos aplicaciones delphi pueden abrir la misma base de datos al mismo tiempo.

// Saludos

Gracias Roman, por la informacion que solicitaba. Ha sido para mi una sorpresa que no me entendiesen una pregunta bastante simple.

De hecho, avances en resolver mi problema parecen indicar que se relaciona con que SQLite3Connection que se incluye en Lazarus se describe como verificado en Windows 32 bits, y mi Windows-7 es de 64 bits, aunque mi instalacion Lazarus es de 32 bits. Y aparte Windows-7 tiene unos locks mas complejos a archivos en uso y el componente de conexion es anterior. Y aun mas, SQLite ultimas versiones, tambien trae otras tecnolgogias que son posteriores al componente de Lazarus.

Me falta probar en mi otra laptop de Windows 32 bits, y luego les platico el resultado.

[ElMug]

Amigos,

ya encontre el problema:

Estaba usando "reset" para verificar el file (base de datos SQLite3) que se abre, en el viejo entendimiento que reset "opens to read". Esto, para evitar crear bases de datos vacias, que es una peculiaridad de SQLite3 (Cuando el archivo no lo encuentra al abrir, SQLite3 crea una base de datos vacia, lista para ser poblada).

Pero "reset", cuando el file ya esta abierto, no regresa zero, aun cuando reset es para "open to read"!

[roman]

Si es para verificar la existencia del archivo puedes usar la función FileExists.

// Saludos

[ElMug]

Empezado por roman

Si es para verificar la existencia del archivo puedes usar la función FileExists.

// Saludos

Si, gracias Roman.

Eso es lo que use.

SQLite3 realmente SI trabaja como dicen sus especificaciones tambien en Lazarus. Ya llevo muchas pruebas que verifican la robustez y gran capacidad de ese animalito.

Es ACID-compliant segun sus especificaciones, y confirmo, dentro de mis limitaciones, que si verifica serlo.

Bueno, hasta luego y gracias a todos.

[[rretamar]]

Vamos a ver: la concurrencia es para operaciones de lectura, porque el hecho que te bloquee la base de datos completa (o sea el archivo completo) al realizar una escritura (aunque más no sea por fracciones de segundo) para mí la descarta en cuanto a uso multiusuario. De acuerdo, se puede mediante código hacer que la aplicación "espere" hasta que la base de datos se desbloquee (cuando otro usuario -o aplicación- escribió) y recién ahí realizar el acceso, pero eso me parece una chapuza. Funciona, pero en ese caso prefiero optar por un verdadero motor SQL cliente-servidor (¿ dije Firebird ? ). Dejemos a SQLite para lo que es, un sistema de base de datos monousuario libre, veloz, sin instalación y altamente portable...en eso no tiene rival.

Firebird en versión "embebido" también bloquea el archivo, pero tiene la ventaja que es mucho más fácil realizar la migración a la versión cliente-servidor común, porque el formato de la base de datos es el mismo.

[ElMug]

Empezado por rretamar

Vamos a ver: la concurrencia es para operaciones de lectura, porque el hecho que te bloquee la base de datos completa (o sea el archivo completo) al realizar una escritura (aunque más no sea por fracciones de segundo) para mí la descarta en cuanto a uso multiusuario. De acuerdo, se puede mediante código hacer que la aplicación "espere" hasta que la base de datos se desbloquee (cuando otro usuario -o aplicación- escribió) y recién ahí realizar el acceso, pero eso me parece una chapuza. Funciona, pero en ese caso prefiero optar por un verdadero motor SQL cliente-servidor (¿ dije Firebird ? ). Dejemos a SQLite para lo que es, un sistema de base de datos monousuario libre, veloz, sin instalación y altamente portable...en eso no tiene rival.

Firebird en versión "embebido" también bloquea el archivo, pero tiene la ventaja que es mucho más fácil realizar la migración a la versión cliente-servidor común, porque el formato de la base de datos es el mismo.

Hola,

Para uso tupido por supuesto que es mejor una base con motor-servidor.

Pero la verdad es que TODOS ellos tambien, ponen las transacciones a "hacer fila de espera". Ninguno escribe simultaneamente al mismo lugar, o campo, o record, realmente, hay que recordarlo.

La GRAN diferencia, es que los servidores de gran rendimiento usan multiples hilos (multi-threaded), y muchos archivos (files), y hasta varios drives, para poder recoger la data que se va a guardar. Y no solo es un cpu el que trabaja, sino que hay VARIOS tipos de servidores (de servicios), tal como si fuera la servidumbre de un hotel, por ejemplo.

El SQLite se contiene todo en un solo archivo. Pero la verdad es que graba archivos temporales tambien, pues de hecho para ser atomica (la "A" de "ACID"), graba la transaccion tambien temporalmente y luego la guarda COMPLETA, o no la graba.

SQLITE hace todo ello "solita", asi que si alguien hace chapuza serian los motores "big boys".

Otra cosa importante es que SQLite se basa en que los "ques" (las esperas y locks) las administra el sistema operativo. Comparar SQLite con los big-boys es como comparar el abarrote de la esquina con un Supermercado, pero SI, ambos son multiusuarios y multiconcurrentes, fundamentalmente.

Igualmente, unas cosas son mas rapidas de adquirir en una tienda o farmacia pequeña que en un supermercado. Muchas operaciones son mas rapidas en SQLite que con los big-boys. Igualmente, si uno es mas facil ser el propietario de una tiendita que de un Supermercado, o una cadena de supermercados (que algunas bases de datos gigantes es lo que son).

Les platico que a SQlite le he hecho todo lo que puedo y se me ocurre. Incluyendo que le cargue varias fotos en Blobs y AUN le cargue dos libros completos en texto, y uno de ellos es El Quijote de Cervantes COMPLETO. Y lo puedo leer sin demoras en un DBMemo! En la MISMA base de datos meti esquemas y data que haye en la red, y las carga y maneja muy bien. Mis desarrollos muchas veces me levantaban excepciones y las ignoraba, y aun no se daña el archivo de pruebas, ya de casi dos gigabytes.

Un detalle que si tiene es que el Path a las bases de datos no debe de ser muy largo, pues luego SQLite protesta diciendo que son muchos parametros.

SQLite es la base de datos de mayor uso en el planeta (por numero de usuarios). Como los autores la hicieron del dominio publico, esta oculta donde menos piensa uno: esta en FireFox, en Google, y en la mayoria de los celulares avanzados. Tambien la Mac la trae incluida, el IPad, etc.

Otro detalle importante es que no usa passwords, y eso no es aceptable en muchisimos casos. Backup es simplemente copiar el archivo unico.

No es la solucion para todo y todos, tampoco.