Igor Sereda <[EMAIL PROTECTED]> wrote:
From API docs:
[quote]
The sqlite3_errcode() interface returns the numeric result code or
extended result code for the most recent failed sqlite3_* API call
associated with sqlite3 handle 'db'. If a prior API call failed but
the most recent API call succeeded, the return value from
sqlite3_errcode() is undefined.
[/quote]
I find this contract very inconvenient, as for each API call I would
like to know exactly whether it had succeeded.
The return value of each API tells you whether it has succeeded or not.
I suppose that the
same contract applies to int return values from sqlite3_* calls --
for example, docs for sqlite3_finalize() state that the return code
can be an error from previous execution of the statement.
That's because of an unfortunate historical behavior of sqlite3_step,
which now has to be maintained for backward compatibility. When
sqlite3_step fails, it returns a generic SQLITE_ERROR code. One has to
follow up with a call to sqlite3_reset or sqlite3_finalize, which
returns the actual error code that sqlite3_step should have returned in
the first place, even though the actual reset or finalize operation
succeeds.
If you use sqlite3_prepare_v2 function to prepare your statement, you
opt out of this legacy behavior and then sqlite3_step returns the actual
error code directly, and sqlite3_reset and _finalize behave in a sane
way.
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
