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]>




Reply via email to