can be interpreted the same as SQLITE_BUSY?
>
> Cheers,
> Dave.
>
>
> -Original Message-
> From: Hynes, Tom [mailto:tom.hy...@inin.com]
> Sent: 06 March 2009 05:10
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] shared cache and SQLITE_M
: 06 March 2009 05:10
To: General Discussion of SQLite Database
Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
Thanks Dan!
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan
Sent: Thursday, March 05
Thanks Dan!
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of Dan
Sent: Thursday, March 05, 2009 10:08 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
On Mar
On Fri, 06 Mar 2009 10:26:38 +0100, Marcus Grimm
wrote:
>The website is allready excellent, I'm not at all complaining...
>
>Anyway, I've placed an updated version of the thread test program on the
>web:
>
>http://www.exomio.de/sqlitethreadtest.c
>
>If somebody found it useful or good enough: Fee
Dan wrote:
> On Mar 6, 2009, at 1:48 PM, Marcus Grimm wrote:
>
>> I just want to add another hint that I learned yesterday:
>>
>> when sqlite3_step() returns SQLITE_LOCKED be aware
>> that sqlite3_reset() will most likely also return
>> SQLITE_LOCKED and thus it is necessary to repeat calling
>>
On Mar 6, 2009, at 1:48 PM, Marcus Grimm wrote:
> I just want to add another hint that I learned yesterday:
>
> when sqlite3_step() returns SQLITE_LOCKED be aware
> that sqlite3_reset() will most likely also return
> SQLITE_LOCKED and thus it is necessary to repeat calling
> it until it returns S
t;>
>> Tom
>>
>> -Original Message-
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org
>> ] On Behalf Of Dan
>> Sent: Thursday, March 05, 2009 12:38 PM
>> To: General Discussion of SQLite Database
>> Sub
e.org [mailto:sqlite-users-boun...@sqlite.org
> ] On Behalf Of Dan
> Sent: Thursday, March 05, 2009 12:38 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
>
>
> On Mar 6, 2009, at 12:22 AM, Marcus Grimm wrote:
-boun...@sqlite.org]
On Behalf Of Dan
Sent: Thursday, March 05, 2009 12:38 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
On Mar 6, 2009, at 12:22 AM, Marcus Grimm wrote:
> Dan,
>
> I'm not sure what you mean by t
the magic MISSUSE.
>>>>>>
>>>>>> Yes, I also tried to call sqlite_reset right
>>>>>> after this first error and in this case
>>>>>> sqlite_reset return the LOCK state. I didn't
>>>>>> yet go on to handl
;>>>>> simplify the code given below. My original code
>>>>>>> checks that and it usually works quite well.
>>>>>>> that's basically the reason why I was puzzled
>>>>>>> by the randomly MISUSE results
one runs
>>>> without any problem, it's my fault, if not: I'll post
>>>> it here for further discussions... ;)
>>>>
>>>> Thanks for your feedback
>>>>
>>>> Marcus
>>>>
>>>>
>>>>> Marc
o the condition when
>>>>> one thread is attempting or holding an exclusive lock
>>>>> while another thread is just doing an sqlite_step (read
>>>>> only)
>>>>> on an allready created statement. Both threads use their
>>>>>
noticed your sample code does not test the return value from
>>> the
>>> sqlite3_prepare_v2 call. Could the code be entering the do loop
>>> when an
>>> error was returned from prepare?
>>>
>>> Just an idea.
>>>
>>>
call. Could the code be entering the do loop when an
>> error was returned from prepare?
>>
>> Just an idea.
>>
>> Have you tried the reset call as DRH had suggested?
>> Your prior post indicated you had more code and another loop. Can you post
>> the fu
; HTH
>
>
>
> --- On Wed, 3/4/09, Marcus Grimm wrote:
>
>> From: Marcus Grimm
>> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
>> To: kennethinbox-sql...@yahoo.com, "General Discussion of SQLite
>> Database"
>> Date: Wednes
ested?
Your prior post indicated you had more code and another loop. Can you post the
full code for both loops?
HTH
--- On Wed, 3/4/09, Marcus Grimm wrote:
> From: Marcus Grimm
> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
> To: kennethinbox-sql...@yahoo
.
>
>
> --- On Wed, 3/4/09, Marcus Grimm wrote:
>
>> From: Marcus Grimm
>> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
>> To: "General Discussion of SQLite Database"
>> Date: Wednesday, March 4, 2009, 10:25 AM
>
wrote:
> From: Marcus Grimm
> Subject: Re: [sqlite] shared cache and SQLITE_MISUSE on sqlite3_step()
> To: "General Discussion of SQLite Database"
> Date: Wednesday, March 4, 2009, 10:25 AM
> Richard, thanks again for the feedback.
>
> However, I don&#x
Richard, thanks again for the feedback.
However, I don't see how it can happend that the statement
is completed internally without returning SQLITE_DONE.
In the particular code of the "reading thread" I do something like:
--
sqlite3_prepare_v2(db, "SELECT * FROM TableA", -1, &stmt, 0);
/** step t
On Mar 4, 2009, at 9:35 AM, Marcus Grimm wrote:
> hi,
>
> OK, the value of p->magic is 519C2973 (VDBE_MAGIC_HALT)
That means the prepared statement has run to completion and needs to
be reset using sqlite3_reset() before you continue.
D. Richard Hipp
d...@hwaci.com
hi,
OK, the value of p->magic is 519C2973 (VDBE_MAGIC_HALT)
that should mean that "VDBE has completed execution"...
I don't know... in that case I should get a SQLITE_DONE
when stepping throu the result set, right ?
Just some additional info:
It is the last sqlite version, threadsafe is true an
On Mar 4, 2009, at 8:31 AM, Marcus Grimm wrote:
> Richard,
> Thanks for looking into this.
>
> I've placed some debug output in the sqlite2_step function
> and I found that it returns SQLITE_MISUSE here:
>
> --
> static int sqlite3Step(Vdbe *p){
> sqlite3 *db;
> int rc;
>
> assert(p);
>
Richard,
Thanks for looking into this.
I've placed some debug output in the sqlite2_step function
and I found that it returns SQLITE_MISUSE here:
--
static int sqlite3Step(Vdbe *p){
sqlite3 *db;
int rc;
assert(p);
if( p->magic!=VDBE_MAGIC_RUN )
{
return SQLITE_MISUSE;
}
On Mar 4, 2009, at 5:19 AM, Marcus Grimm wrote:
> Hi all,
>
> I'm doing a little stress test on a server application and run into
> a problem when two threads are trying to access the database.
> Here is the background:
> 1. shared cache is enabled prior open any DB connection.
> 2. Each thread t
Hi all,
I'm doing a little stress test on a server application and run into
a problem when two threads are trying to access the database.
Here is the background:
1. shared cache is enabled prior open any DB connection.
2. Each thread then opens a DB connection.
3. Thread A just reads table entries
26 matches
Mail list logo
