Yes this is with the 3.3.14 code. I initially got the problem with the 3.3.12
code so I just upgraded to the 3.3.14 code but it behaves exactly the same.
Just to recap, my proposed fix was
//---
while( rc == SQLITE_SCHEMA )
rc = prepare_v2;
// Some generic rc error checking here for prepare_v2
rc = step;
if( rc == SQLITE_SCHEMA )
finalize;
continue;
end;
// Some generic error checking for the step!=SQLITE_SCHEMA
You proposed:
//---
rc = prepare_v2;
// Some generic rc error checking here for prepare_v2
while( rc == SQLITE_SCHEMA )
rc = step;
if( rc == SQLITE_SCHEMA )
reset;
continue;
end;
// Some generic error checking for the step!=SQLITE_SCHEMA
The proposed method works and I will change mine to work like that. Still is
this the way it is done or am I missing something. I thought step is
supposed to handle SQLITE_SCHEMA errors automatically.
Regards,
Werner
Dan Kennedy-4 wrote:
>
> On Thu, 2007-04-05 at 04:04 -0700, pompomJuice wrote:
>> Ok.
>>
>> I went and re-prepared the statement anyway even though the documentation
>> says it won't work. This trick only works if you finalize the failed
>> statement after the step command. Otherwhise you keep on getting
>> SQLITE_SCHEMA errors which might cause and endless loop if so
>> implemented.
>>
>> Interesting.
>
> Is this with 3.3.14 code? Also, do you know if there are any other
> statements created with the same db-handle that have been
> sqlite3_step()'d but not sqlite3_finalized()'d or sqlite3_reset()'d?
>
> Finally, instead of re-prepairing the busted statement, what happens
> if you sqlite3_reset() it and then try to run it again?
>
> Dan.
>
>
>>
>> pompomJuice wrote:
>> >
>> > Hello.
>> >
>> > I recently rewrote most of my SQLite wrappers to now ignore SCHEMA
>> errors,
>> > as these are now automagically handled by the new sqlite3_prepare_v2
>> API.
>> > The logic changes were simple so I did not bother to test it and
>> continued
>> > with development. Now that development is complete and testing started
>> > again I am getting the same old schema errors I use to get with the
>> > deprecated prepare API. Only now I can’t get rid of them as
>> re-prepairing
>> > with v2 won't make the problem go away.
>> >
>> > I am therefore inclined to think that I am trying to use SQLite in a
>> way
>> > that is not permitted. Basically what I have is one .db file that is
>> being
>> > accessed by multiple binaries. If one binary drops or adds
>> tables/indexes
>> > the other binary fails with the schema error. There is no way that I
>> can
>> > rather use one binary with multiple threads.
>> >
>> > So my question is. Can SQLite recover from schema changes caused by
>> other
>> > processes or do I need to revert to the deprecated prepare API?
>> >
>> > Many thanks for any help in this regards.
>> >
>> > Werner.
>> >
>> >
>> >
>> >
>>
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
>
>
--
View this message in context:
http://www.nabble.com/sqlite3_prepare_v2-schema-error-Fatal%2C-need-help-please.-tf3530348.html#a9854974
Sent from the SQLite mailing list archive at Nabble.com.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
