Indeed if I reset after the first step failed, and than prepare again, the select works. But I guess this is not the usual way to do things right? I mean - shouldn't the first prepare be aware of the fact that the database was changed? Or maybe CREATE TABLE is a special case?
On 5/23/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 5/23/06, Robert Simpson <[EMAIL PROTECTED]> wrote: > > That doesn't seem right. > > The change was made and committed then the database statement > > prepared. > > The change should have already been written so the prepare > > should have gotten the latest stuff. Does it need to be > > closed and reopened for a schema change to be recognized?= > > Beats me, but that's the way it seems to work. You should always reset() a > statement after a failed step(), and check the reset()'s error code to see > if it's SQLITE_SCHEMA. If it is, you should re-prepare the statement. I > don't think it matters when the statement was prepare()'d as long as you > follow that rule. It was prepared after the schema was changed and written to disk. That seems pretty unintuitive to me. When you prepare the statement it evidently doesn't use the current schema, though it knows the schema has changed... I guess that implies the call to reset() reloads the schema I'll check that
