(Sorry, accidentally dropped the sqlite mailing list from my first reply)
You're misunderstanding. The only "schema change" is creating
additional tables, that are not referenced by any existing statements.
There are many reasons why one might want to do this. However,
currently, doing so invalidates all prepared statements -- which is
fine. However, SQLite should, IMO, be able to recover from that
internally instead of requiring the user to supply a cut-and-paste
recovery mechanism.
- Vlad
On 4/21/05, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> Ah.
> Changing the schema of a running system is bad news.
> Shouldn't your schema be thought out carefully before you write code?
> Even if the design changes after you implement the changes should be
> thought out and a transition planned. As the old joke goes
> "Doctor! Doctor! It hurts when I..."
>
> On 4/21/05, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote:
> > On 4/21/05, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> > > I've been using sqlite for several months now and have never had a
> > > SQLITE_SCHEMA
> > > error. What are you doing that's causing it?
> >
> > There's been a few threads on the list in the past months about the
> > various causes; there's an entry in the SQLite FAQ about it as well.
> > In a nutshell, opening the same database multiple times and then
> > creating a new table on one of those connections invalidates any
> > prepared statements on the other connections, resulting in
> > SQLITE_SCHEMA when _finalize() is called (which also makes no sense to
> > me -- I want to find out about SQLITE_SCHEMA before I finalize, why
> > not in reset()?).
>
