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