[EMAIL PROTECTED] wrote:
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR. Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code. Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by sqlite3_step(). That would mean that
moving from version 3.2.7 to 3.3.0 might involve some
minor code changes. The API would not be 100% backwards
compatible. But the API would be cleaner.
What does the community think about such a change?
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors. But sqlite3_stmts would use a little more
memory. And sqlite3_step might take a little longer
to initialize sometimes if it found it needed to rerun
the parser.
What about this change? Is it a worth-while tradeoff?
--
D. Richard Hipp <[EMAIL PROTECTED]>
I think both of these proposed changes are useful enhancements to SQLite.
I also think it would be better to add a new sqlite3_step_v2() API
function that does this. This will eliminate the need to change the base
version number, since existing code can continue to use the existing
step function. New code, or those who want to modify their existing
code, could use the new function.
The new step function should be a wrapper around the existing step
function in much the same way as sqlite3_exec() wraps the entire
prepare, step, finalize process. It would do the enhanced error checks
and return the real error, or automatically re-prepare the SQL if the
error was SQLITE_SCHEMA.
This would give you the best of both worlds, backwards compatibility and
a cleaner API for new code.
Dennis Cote
