I submitted a bug with a similar problem a while back:
http://www.sqlite.org/cvstrac/tktview?tn=1366
the bug was closed with this comment by drh:
"SQLITE_CORRUPT gets returned when you call sqlite3_reset() or
sqlite3_finalize().
This is unfortunate, I know. We should have designed the API so that the
specific error was returned directly from sqlite3_step(). But we didn't.
And nobody commented on the problem during the beta period. We cannot
change it now without breaking backwards compatibility. So we are stuck
with the current mode of operation."
We changed our code so that in the face of an error from sqlite3_step(),
we call sqlite3_reset(), which then at least in the case I was testing
(looking for SQLITE_CORRUPT) returns the right error code.
Cariotoglou Mike wrote:
when a sqlite3_Step call fails, say on a unique key violation of an
INSERT statement,
the returned error code is SQLITE_ERROR, which is documented.
calling sqlite3_errcode at this point, however, also gives the same
error, which is not.
the correct error, which is SQLITE_CONSTRAINT, is only returned when
calling sqlite3_finalize, which may happen at a much later stage in the
code.
I believe the error code should be returned right at the point where the
error happens, because if it is not, the structure of the code suffers,
since the finalization code for a
statement needs to be modal.
