At 14:18 03/11/2005, you 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.
Yes 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.
What about this change? Is it a worth-while tradeoff?
That i don't understand. So, there are 2 scenarios
a) sqlite3.2 process a SQL transaction while a potentially
SQLITE_SCHEMA error transaction is on the road.
b) sqlite3.2 begins a potentially SQLITE_SCHEMA error transaction
while others transactions are on the road.
Isn't better lock the database while a transaction that can make a
SQLITE_SCHEMA error, as is done with writes? A change in database is
always a change. Also that way you don't waste time in rerunning the
affected transactions.
-----------------------------------------------------------------------------------------
Useful Acronymous : FAQ = Frequently 'Answered' Questions
