Just out of personal interest:
Could you detail on which versions of Windows it works, and on which it
doesn't?
Thanks
Rolf
[EMAIL PROTECTED] wrote:
"Jay Sprenkle" <[EMAIL PROTECTED]> wrote:
On 3/2/06, Vishal Kashyap <[EMAIL PROTECTED]> wrote:
Dear All ,
Wanted to know if we can
- Original Message - From: "Rolf Schaeuble"
<[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, September 14, 2005 2:43 PM
Subject: Re: [sqlite] Re: Thread safety guarantees
That doesn't work for me. During one single transaction several
threa
Dennis Jenkins wrote:
Rolf Schaeuble wrote:
Hello,
if I understand the whole issue correctly, there is only one reason
why it's not safe to use a sqlite handle in any thread of a process
(as long as only one thread at a time uses it): File locks are tied to
the thread that created them
Hello,
if I understand the whole issue correctly, there is only one reason why
it's not safe to use a sqlite handle in any thread of a process (as long
as only one thread at a time uses it): File locks are tied to the thread
that created them (except this special Redhat version). That's why
What do you mean with "Multithreaded" or "Mulithreaded-DLL" project? Can
you explain exactly where you can select between these two options, and
whether you are using Visual Studio 6 or 2002/2003?
Rolf Schäuble
Michael Knigge wrote:
Hello,
this question is slightly OT here but.
I want to
Thanks. Now it's clear what's going on.
Thank you for this great piece of code.
Rolf
D. Richard Hipp wrote:
Rolf Schaeuble wrote:
Hello,
I've had a look at pager.c to understand what's going on in there.
While I think I understand most of it, there's one point I don't
understand:
The comment
D. Richard Hipp wrote:
Rolf Schaeuble wrote:
There are other places in sqlite3pager_get where SQLITE_IOERR are
returned; I've not checked whether these can also be triggered by the
db being locked or if they indicate serious problem.
If someone is interested, I can send a test case
Hello,
I stumbled over some quite strange case.
Here's the easiest test case that triggers the behaviour:
One process performs very long reads from a db (multiple joins, so the
cartesian product is *very* large, and the reader needs a while to
complete).
Another process performs a "BEGIN
Hello Roger,
thanks for your answer.
Answers inline.
Roger Binns wrote:
itself. However, I'm afraid that this will not lead to the best
possible performance.
If you want the best possible performance then don't use SQLite at all
and instead make your own file format that exactly meets your
Hello All,
I'm sure this questions has already been asked thousands of times, but
after searching the archive I still don't know the definite answer.
Is it safe to access the same instance of an sqlite3 database (the same
pointer returned by sqlite3_open) in several threads, provided that the
Right. I'm sorry.
I should get rid of this CC'ing habit ;-)
Rolf
D. Richard Hipp wrote:
[EMAIL PROTECTED] wrote:
P.S.: I have put Mr. Hipp on CC because after many hours of testing and
reading up on SQL (that's basically all I did today), I'm quite
convinced that there's a bug.
I read the
Hello,
today I've stumbled over a problem that I can't seem to find an answer for.
I have the following tables:
CREATE TABLE object (
object_id INTEGER PRIMARY KEY
);
CREATE TABLE properties (
object_id INTEGER,
property_id INTEGER,
value_table INTEGER
);
CREATE
12 matches
Mail list logo
