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