[EMAIL PROTECTED] wrote:
"Andrew Shakinovsky" <[EMAIL PROTECTED]> wrote:
According to the docs, I am asked to finalize the
statement [after SQLITE_SCHEMA], and re-prepare it. Unfortunately
this doesn't fit nicely into my architecture.
It is easy to put wrappers around sqlite3_prepare(),
sqlite3_step(), and sqlite3_finalize() to fix this.
Have your sqlite3_prepare() wrapper return an object
that holds both the sqlite3_stmt* and a copy of the
original SQL text. The sqlite3_step() wrapper (which
can be a method on the previous object) should call
sqlite3_reset() if it finds an error, and if the error
is SQLITE_SCHEMA, it can prepare a new sqlite3_stmt,
transfer bindings from the old to the new, finalize
the old, and retry the sqlite3_step(). The sqlite3_finalize()
wrapper is just the destructor on the object that
your sqlite3_prepare() wrapper returned.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Richard,
Wouldn't it make sense to include this functionality in the SQLite
library. It would only need to be implemented once, not over and over
again by each of your users, and it could be thoroughly debugged,
optimized, and tested like the rest of the SQLite code.
I think that adding a few new APIs to do this (and clean up the error
return mechanism for sqlite3_step/sqlite3_finalize) would be a
substantial improvement to SQLite. The existing APIs would remain
unchanged for backward compatibility. The new APIs would be implemented
using the existing APIs so there would be no danger of the old APIs
being abandoned over time.
Just my two cents.
Dennis Cote
