Angus March <an...@uducat.com> wrote: > Igor Tandetnik wrote: >> Angus March <an...@uducat.com> wrote: >>> After the callback has finished, what will happen with that original >>> call to sqlite3_reset()? >> >> Since sqlite3_reset doesn't take any locks, a busy callback would >> never be invoked for it. > > Well someone should tell the library on my machine that, because > it's returning locking errors
I didn't say that sqlite3_reset can't return SQLITE_BUSY - only that it doesn't take locks and doesn't trigger a call to a busy handler. For historical reasons, for statements prepared with sqlite3_prepare[16], sqlite3_step reports all errors with a generic SQLITE_ERROR code. A subsequent call to sqlite3_reset or sqlite3_finalize returns the real error code (even though the reset or finalize itself doesn't fail). Use sqlite3_prepare[16]_v2 to avoid this behavior and have sqlite3_step return the real error code directly. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
