Thank you for your answer,
Finally I can use sqlite very well on a multi-threading environment.
I can run six threads with an maximum of 25% of processor busy. For each
thread I have a new pointer for my wrapper class over sqlite(another connection.. etc...).
Thank you.
but, I have another question... It is possible this kind of statement?
SELECT id, code FROM a WHERE
(code IN
(SELECT code FROM
(SELECT code, COUNT(code) AS c FROM a GROUP BY code) AS aaa WHERE c > 1)
)
and ORDER BY code
so this query check if the code appears more than once a time in the table -A-
I run this kind of query but i got an error.
The query is functional, cause I run the same query in sql server, in a database with the same structure.
Thank you a lot.
----- Original Message ----- From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Saturday, April 16, 2005 2:11 AM
Subject: Re: [sqlite] multi threading
On Fri, 2005-04-15 at 14:44 +0300, Cosmin Vlasiu wrote:Hello to everyone,
I have a question... regarding multi-threading...
the question is for microsoft windows (a visual c++ application)... I saw
the documentation
and I understood that for microsoft OS, the multi-threading is
enabled by default.
So, of course I start two threads, both of them make a loop into a
"recordset".
the first thread it works good, but the second, no way. I made kind of
research
in the documentation and I observed that I have to make new connections for
each thread.
All donne. But when I run the application I got the same problem.
In the second thread the sqlite3_prepare function always return the 21 value
that means SQLITE_MISUSE, because sqlite3SafetyOn retun 1.
Can somebody tells me if there is a solution for that problem?
Two separate threads may not use the same database handle at the same time. If they do, the SQLITE_MISUSE value is often returned. Separate threads should have their own database handles.
I know you said above that you are using separate database handles in your two threads. But probably there is a bug in your code that is preventing this from happening really.
My advice to *all* programmers is to never use more than one thread in the same address space. I have never in 20 years worked on a multiple threaded program that actually got all of the threading issues right. There are always subtle bugs that cause error that are very difficult to reproduce and fix. Multithreading is the fastest road to buggy code that I know of. Avoid it. If you absolutely, positively must have multiple threads of control, put each thread in its own address space (make it a process.) -- D. Richard Hipp <[EMAIL PROTECTED]>