----- Original Message -----
From: <[EMAIL PROTECTED]>
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.
This is a good change and though it'll require some code changes on my part,
I'm all for it.
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.
This is one gives me pause. I see lots of people doing things like this in
their code (Using C# since I address this in my wrapper's helpfile and its
convenient):
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
int n;
for (n = 0; n < 100000; n ++)
{
mycommand.CommandText = String.Format("INSERT INTO [MyTable] ([MyId])
VALUES({0})", n + 1);
mycommand.ExecuteNonQuery();
}
}
I try to discourage this sort of thing, but so many people do this and
they'll be hit with a stiffer penalty under the proposed change.
IMO schema change errors are an outside case, and preventing them by
introducing this change would only penalize users that have already either
coded around this issue or don't experience it at all.
Robert
