Well, I guess I was not clear in my explanations.
I'm already doing my own locking, that's the problem!
But I'm not sure how to improve it.
...
At which stage the data will be saved it and.
that will froze the application because the search/select already get the
database lock.
If you
How about putting the update into in it's own thread and just wait
till any locks are released?
I though of that but think it's annoying, what if the user want to Quit the
application?
Should he wait for all the thread to perform...
But someone give me a good idea, I could make a copy of the da
> Well, I guess I was not clear in my explanations.
> I'm already doing my own locking, that's the problem!
> But I'm not sure how to improve it.
...
> At which stage the data will be saved it and.
>
> that will froze the application because the search/select already get the
> database lock.
Well, I guess I was not clear in my explanations.
I'm already doing my own locking, that's the problem!
But I'm not sure how to improve it.
My problem here is the following: I am doing a search through all record,
could be long. Do some string matching, cutting, etc with all text of all
records
qlite3.dll from
www.sqlite.org.
Again, any help would be appreciated.
Mike.
-Original Message-
From: Igor Tandetnik [mailto:[EMAIL PROTECTED]
Sent: 21 October 2005 02:38 PM
To: SQLite
Subject: [sqlite] Re: Multithreading Question
Michael J. Sviridov wrote:
I've got two thr
mailto:[EMAIL PROTECTED]
Sent: 21 October 2005 02:38 PM
To: SQLite
Subject: [sqlite] Re: Multithreading Question
Michael J. Sviridov wrote:
> I've got two thread's (with unique db handles), each thread does the
> following:
>
> BEGIN EXCLUSIVE TRANSACTION;
> (60,000 INSE
Michael J. Sviridov wrote:
I've got two thread's (with unique db handles), each thread does the
following:
BEGIN EXCLUSIVE TRANSACTION;
(60,000 INSERT OR REPLACE statements into the same table)
COMMIT TRANSACTION;
This works fine, as expected, one thread acquires the lock and the
other thread w
7 matches
Mail list logo
