After a prepared statement has commenced execution, there is no change that can be made by alter table on that connection which can cause a change which would effect the correct execution of the query. What sort of ALTER TABLE do you think could be issued that would make the execution invalid and need the statement to be re-prepared during execution? And statements which would "conflict" with the executing statement (such as an attempt to drop one of the tables or indexes being actively used) would get a locked error. Hopefully an ALTER TABLE ... DROP COLUMN ... would also result in the same locked error -- but you do not have to worry about that (yet) since the ability to use ALTER TABLE to drop a column does not exist. So it is not possible for a statement to be "re-prepared" during execution (not to mention the obvious question of how the execution would be "re-stepped" to the same place so that it could "carry on" if that were possible. So a re-prepare can only occur for a statement that is not yet executing (ie, on the first call to `sqlite3_exec` -- the one that causes the VDBE code to enter the executing state). A `sqlite3_reset` causes the execution to end, and a subsequent call to `sqlite3_exec` on the same statement is a "first call" to the statement and thus may re-prepare the statement if the schema has changed since it was last prepared. All table / column names have already been resolved in the VDBE code, so even if you did change the "name" of a column, add a new "column", or change the name of a table, those changes would have no effect on the execution of the VDBE code nor the correctness of the result.