Foros Club Delphi
Página 1 de 2 1 2 >
Mostrar 40 mensajes desde este tema en una página

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Conexión con bases de datos (https://www.clubdelphi.com/foros/forumdisplay.php?f=2)
-   -   SQLite3 aplicaciones Delphi en misma base de datos? (https://www.clubdelphi.com/foros/showthread.php?t=79886)

ElMug 19-08-2012 10:23:07
SQLite3 aplicaciones Delphi en misma base de datos?
 
Hola amigos,

Solicito me informen si con AplicacionX hecha con Delphi, corriendo dos veces, pueden abrir la misma base de datos de SQLite3 simultaneamente.

Tambien que componente usan para abrir el SQLite (Zeos) o algun otro.

Aqui con Lazarus y los componentes incluidos Aplicacion-X abre la basededatos, y otra instancia de Aplicacion-X ya no la puede abrir.

Y si dos aplicaciones se pueden conectar a la misma base de datos, ambas pueden modificar, datos (no necesariamente al unisono, sino cambiar un dato con una de las instancias, y enseguida cambiar otro dato con la otra instancia, de prefrencia en la MISMA tabla)?

Gracias.

Casimiro Notevi 19-08-2012 11:06:13
En la web de sqlite explican todo lo que preguntas, por ejemplo:

Cita:
Can multiple applications or multiple instances of the same application access a single database file at the same time?
Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.

ElMug 19-08-2012 19:39:29
Eso ya lo se, Casimiro.

Pero esa no es mi pregunta, ni es esta la respuesta a la pregunta.

Gracias por tratar de ayudar.

Casimiro Notevi 19-08-2012 19:48:16
Ya veo que ni lo has leido ;)

rretamar 19-08-2012 19:59:28
Al grano: SQLite es para uso en aplicaciones monousuario. Es más un reemplazo (muy avanzado) de las "tablas planas" (Paradox, XBase, Access) que un verdadero motor SQL cliente-servidor. Si necesitas accesos concurrentes lo mejor es utilizar Firebird.

ElMug 20-08-2012 00:56:59
Cita:
Empezado por rretamar (Mensaje 439943)
Al grano: SQLite es para uso en aplicaciones monousuario. Es más un reemplazo (muy avanzado) de las "tablas planas" (Paradox, XBase, Access) que un verdadero motor SQL cliente-servidor. Si necesitas accesos concurrentes lo mejor es utilizar Firebird.
No, no es asi.

Tengo aplicaciones por otros que permiten uso concurrente exactamente con la funcionalidad requerida. Pero no hay informacion de como lo hacen, y no se en que plataforma se han desarrollado.

SQLite de por si tiene la facilidad de permitir uso concurrente y debe de poderse abrir simultaneamente por aplicaciones que lo hagan correctamente. Y pueden grabar datos ambas, mas durante los milisegundos que tarda en grabar una, la otra se espera.

Esto ya lo verifique, y tambien esta descrito en varios lugares en el web.

No es tipo servidor, claro, pero SI permite uso concurrente. Y mi pregunta es si con aplicaciones Delphi esto alguien lo ha logrado y que componentes usa.

Los componentes, por ejemplo de Devart, especifican que PUEDEN HACER ESO, y en caso necesario, los adquiriria.

Pero, antes solicito saber si con Delphi eso ya se logra o no .

Con Lazarus y sus componentes incluidos, aun no lo logro.

Claro que SQLite no es para tupirle datos de muchos usuarios simultaneos con cordinacion por el motor de la base de datos, pues no es tipo servidor.

Pero si se debe de poder accesar por mas de un usuario, contimas si el usuario es uno mismo y localmente.

Hispanohablante 20-08-2012 01:51:55
Me parece que quiso decir "acceder" donde dice "accesar". Por otro lado y aunque mi inglés no es bueno, creo que el moderador le dio una muy buena referencia que no merecía tan exiguo agradecimiento (esto último puede ser solamente una mala interpretación de mi parte).

De cualquier manera le extiendo a usted mis respetos, y al moderador le agradezco por la valiosa información que ha compartido.

Casimiro Notevi 20-08-2012 02:13:37
Cita:
Empezado por Hispanohablante (Mensaje 439972)
De cualquier manera le extiendo a usted mis respetos, y al moderador le agradezco por la valiosa información que ha compartido.
¡¡¡ Gracias !!! :)

ElMug 20-08-2012 02:22:18
Esto es a lo que me refiero: (viene del sitio oficial de SQLite3):

We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.

Y la pagina es:
http://www.sqlite.org/lockingv3.html

Y la pregunta especifica es: Alguien lo ha logrado con aplicaciones Delphi? Y de ser asi, con que componentes?

Casimiro Notevi 20-08-2012 02:43:12
Cita:
Empezado por Casimiro Notevi (Mensaje 439932)
En la web de sqlite explican todo lo que preguntas, por ejemplo:
Cita:
Can multiple applications or multiple instances of the same application access a single database file at the same time?
Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
SQLite uses reader/writer locks to control access to the database. (Under Win95/98/ME which lacks support for reader/writer locks, a probabilistic simulation is used instead.) But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the Share.exe daemon. People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true, sharing an SQLite database between two or more Windows machines might cause unexpected problems.
We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.
Cita:
Empezado por ElMug (Mensaje 439976)
Esto es a lo que me refiero: (viene del sitio oficial de SQLite3):

We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.

Y la pagina es:
http://www.sqlite.org/lockingv3.html

Y la pregunta especifica es: Alguien lo ha logrado con aplicaciones Delphi? Y de ser asi, con que componentes?

Amigo, no te enteras.

ElMug 20-08-2012 02:50:38
Cita:
Empezado por Casimiro Notevi (Mensaje 439977)
Amigo, no te enteras.
Te empeñas en no contestar la pregunta, o no entenderla, Casimiro.

Si no sabes contestarla, o no usas SQLite3, pues no deberias de insistir en señalar al projimo, causando solo repudio y polemicas totalmente innecesarias.

Casimiro Notevi 20-08-2012 03:13:28
No es concurrente, así que lo que pretendes hacer no se puede conseguir porque sqlite no es una "auténtica" base de datos multiusuario y multitarea.
Ya lo pone en el texto "que has encontrado" y ya te lo han comentado otro compañero.
No puedes encontrar ningún componente que hagas lo que quieres porque la BD no lo permite, no tiene nada que ver con los componentes que uses.

Si quieres conseguir lo que pretendes, haz caso a los propios creadores de sqlite, ya lo dice en el texto de ellos (extraido del texto que te puse al principio):
Cita:
However, client/server database engines (such as PostgreSQL, MySQL, or Oracle) usually support a higher level of concurrency and allow multiple processes to be writing to the same database at the same time. This is possible in a client/server database because there is always a single well-controlled server process available to coordinate access. If your application has a need for a lot of concurrency, then you should consider using a client/server database. But experience suggests that most applications need much less concurrency than their designers imagine.
Y como dice rretamar, también Firebird.

Por cierto, en todos tus mensajes deja muy claro que no sabes y, sin embargo, descalificas a los que te contestan, que te contestan porque saben.
Una cura de humildad te vendría bien.
Saludos.

ElMug 20-08-2012 04:31:17
Cita:
Empezado por Casimiro Notevi (Mensaje 439979)
No es concurrente, así que lo que pretendes hacer no se puede conseguir porque sqlite no es una "auténtica" base de datos multiusuario y multitarea.
Ya lo pone en el texto "que has encontrado" y ya te lo han comentado otro compañero.
No puedes encontrar ningún componente que hagas lo que quieres porque la BD no lo permite, no tiene nada que ver con los componentes que uses.

Si quieres conseguir lo que pretendes, haz caso a los propios creadores de sqlite, ya lo dice en el texto de ellos (extraido del texto que te puse al principio):

Y como dice rretamar, también Firebird.

Por cierto, en todos tus mensajes deja muy claro que no sabes y, sin embargo, descalificas a los que te contestan, que te contestan porque saben.
Una cura de humildad te vendría bien.
Saludos.
Tu inerpretacion no es correcta, Casimiro.

SQLite es multiconcurrente, y aun se puede usar (y se usa) en websites.

Si lees mas detenidadmente la informacion de SQlite, inclusive la que tu mismo citas, te darias cuenta de que SI es multi usuario.

Los locks que pone SQLite3 no se comparan con los de una basededatos tipo servidor, pero aun ellas tambien detienen el acceso al escribir datos mediate "ques".

Ademas, ya explique que tengo una aplicacion que permite la funcion como me interesa. Con dos aplicaciones de ella, abro la misma base de datos y puedo usarlas yo mismo, leer y escribir sin problemas. Lo mismo es posible con mas usuarios sobre la misma base de datos.

Desde luego no pretendo decir ni he dicho que SQLite sea igual que Postgres o Oracle en cuanto a multiusuarios y administracion de transacciones.

Si no hay respuestas, procedo a investigar los componentes de Devart, que claramente especifican que puede lograr lo que pregunte.

Aqui esta esta cita de Devart (no es mi antojo):
SQLite technology support

  • SQLite database encryption in Direct mode
  • Custom SQLite to Delphi data type mapping
  • Concurrent access <=========================ESPERO SEA CLARO ESTO
  • Shared-Cache mode
  • Read Uncommitted<----------------TAMBIEN ESTO ES IMPORTANTE
  • SQLite user-defined functions
  • Foreign keys
  • Autoincrement
  • Fast record insertion with the TLiteLoader component
La cita de Devart indica que aprovecha las funciones ya de por si de SQLite.

Casimiro Notevi 20-08-2012 09:26:59
Según dicen ellos mismos, usan bloqueos de lectura/escritura, así que aunque puedan haber varios clientes conectados al mismo tiempo, no pueden actuar al mismo tiempo, eso no es concurrencia.
La explicación que dan es que normalmente las lecturas/escrituras tardan poco y apenas tienen que esperar los otros clientes. Pero eso no es multiconcurrencia real, eso es tú primero, ahora yo, después el otro, ahora otra vez tú, etc. pero no todos al mismo tiempo. No es multiconcurrente.
Ahora bien, que a ti te viene bien ese sistema para el trabajo que estás haciendo, entonces perfecto.

roman 20-08-2012 18:19:34
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 Notevi 20-08-2012 18:45:19
Entonces "alguien" :o 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 20-08-2012 18:48:08
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 20-08-2012 21:57:45
¿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 21-08-2012 12:06:26
Cita:
Empezado por roman (Mensaje 440028)
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 22-08-2012 03:51:56
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"!


La franja horaria es GMT +2. Ahora son las 05:03:01.
Página 1 de 2 1 2 >
Mostrar 40 mensajes desde este tema en una página

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi