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. 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. > > > > -- View this message in context: http://www.nabble.com/sqlite3_prepare_v2-schema-error-Fatal%2C-need-help-please.-tf3530348.html#a9853741 Sent from the SQLite mailing list archive at Nabble.com. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
