On Sun, 2005-07-10 at 15:34 -0700, Tim McDaniel wrote: > > > > If another thread or process VACUUMs the database or creates > > a new table or makes any other structure changes to the > > database file, all of your prepared statements will be > > invalided and you will have to rerun sqlite3_prepare(). > > Since you generally have no control over when another process > > might VACUUM the database, you should always be prepared to > > rerun sqlite3_prepare() if necessary. This is true even if > > you are only running your SQL statement once and then > > finalizing it because another process might VACUUM and > > invalidate your statement in the very brief window of time > > between your calls to sqlite3_prepare() and sqlite3_step(). > > > > Your best bet it to use a wrapper class of some sort that > > automates the task of rerunning sqlite3_prepare() when necessary. > > > > Does sqlite store the SQL text passed into sqlite3_prepare? > If not, then I assume this means that any time we use sqlite3_prepare, > we should cache the SQL text "in the wrapper" in case we need to > re-prepare it.
Yes. The wrapper needs to keep the SQL text because SQLite does not. > Along the same line, I suppose we have to cache all the bound > parameters, since they will have to re-bound as well. You can do that. Or you can keep the old prepared statement around until after the new one is ready, then use the sqlite3_transfer_bindings() API to transfer all your bindings from the old to the new, then finalize the old. > > Is it possible to get the SQLITE_SCHEMA error after the first > sqlite3_step call, while iterating throw the rows? > No. SQLITE_SCHEMA will always appear immediately or not at all. -- D. Richard Hipp <[EMAIL PROTECTED]>
