obviously it will never be perfect . We already know the benefits of
each database , including those of SQLITE . This is not because there is
a benchmark that people are not going to look at all the other features.
But in equal hardware, it gives a small indication of current
performance, as
It would be great if someone could redo these tests with the current
versions of the databases.
Jim Callahan a ?crit :
> There is a historical and unfair (specially compiled version of SQLite
> against default settings of PostgreSQL) benchmark
> available on this page, but now that you
sleeping. Or just set the timeout value to zero and deal
> with retries manually in your application.
>
> olivier vidal <mailto:vidal.olivier at mac.com>
> mardi 9 f?vrier 2016 09:41
>
> Hello,
>
> I use SQLITE with Xojo (formerly Realbasic), a kind of VB
> multipl
Hello,
I use SQLITE with Xojo (formerly Realbasic), a kind of VB multiplatform.
Xojo embeds a SQLITE 3.9.2 database.
It works well. But I have a concern, and I do not know if it is a Xojo
problem, or a SQLITE problem.
I am creating an application with Xojo/Sqlite.
This application launches
Hello,
I use SQLITE with Xojo (formerly Realbasic), a kind of VB multiplatform.
Xojo embeds a SQLITE 3.9.2 database.
It works well. But I have a concern, and I do not know if it is a Xojo
problem, or a SQLITE problem.
I am creating an application with Xojo/Sqlite.
This application launches
ctual change to the
> database (a subsequent DELETE, INSERT, or UPDATE) before acquiring the
> write lock. That means that even though the "BEGIN" was successful,
> the next write operation might fail with an SQLITE_BUSY error if
> another thread or process jumps in line ahead of
Hello all,
I would like to be sure I understand the difference between an IMMEDIATE
transaction and a DEFERRED transaction, in WAL mode.
Sorry for my bad english.
Here is what I understand:
Example of an IMMEDIATE transaction:
- BEGIN IMMEDIATE TRANSACTION
- SELECT
- UPDATE
- SELECT
- UPDATE
E puts a
> write-lock on the database immediately. BEGIN EXCLUSIVE puts a
> read-lock and write-lock on the database immediately.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.
mmediately. BEGIN EXCLUSIVE puts a
> read-lock and write-lock on the database immediately.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo
Hello,
some questions please about transactions/locks in a multithreaded
environment, multiple applications,
WAL mode, NO shared cache, NO read_uncommitted pragma:
Some examples:
1-
UPDATE
Internally, is the same thing that: BEGIN DEFERRED - UPDATE -COMMIT?
2-
SELECT
UPDATE
In
_
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> Olivier Vidal <mailto:paxdo at mac.com>
> 1 mars 2015 10:22
> ok, thank you Simon and Kei
practice
> are combined: nothing works and no one knows why.
>
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-us
Hello all,
According to this paragraph http://www.sqlite.org/faq.html#q5, multiple
applications or multiple instances of the same application can access
the *same* database at the *same time*. Even in WAL mode?
If I have understood correctly, all applications will be able to read
the sqlite
13 matches
Mail list logo
