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 throu table result **/
do
{
rc = sqlite3_step(stmt);
if( rc == SQLITE_MISUSE )
{ fprintf(stderr, "ERROR...\n"); break; }
else
if( rc == SQLITE_ROW )
read_data_etc();
else
break;
}while( rc != SQLITE_DONE );
sqlite3_finalize(stmt);
--
The prepare statement pointer is defined locally and no other
thread can access it, except sqlite internal maybe.
To me it looks that in case a parallel thread is inserting or
updating data, the above loop is somehow affected and returns the
MISUSE.
Your reply so far indicates either a bug on my side or a missusage.
I'll go on and try to find the reason why the magic number is resetted
without knowing from calling functions.
calling sqlite3_reset in these cases is difficult for me since it might
not be the first step and previous data is allready in use in the upper loop.
But maybe an option for the very first step if that fails... hm... I'll try
that.
Thanks again
kind regards
Marcus Grimm
D. Richard Hipp wrote:
> 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
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
