On 4 Feb 2014, at 8:49pm, Igor Tandetnik <i...@tandetnik.org> wrote:
> If it is unable to promote the lock, then the in-memory cache will be left in > an inconsistent state and so the error code is promoted from the relatively > benign SQLITE_BUSY to the more severe SQLITE_IOERR_BLOCKED. This error code > promotion forces an automatic rollback of the changes. See the > CorruptionFollowingBusyError < > http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError > wiki page > for a discussion of why this is important. This explanation is useful, but the fact that someone needed it is one of the problems with SQLite3. Given a combination of an API call and a result code it's too difficult to tell whether a programmer should do ROLLBACK. Is there a simple rule that applies to all API calls ? Something like "if you get _BUSY, do this, if you get _IOERR_BLOCKED, do that, if you get _IOERR_LOCK, do that," etc. no matter which call you did ? Is it as simple as "If you get any of these errors for any of these calls, the only useful thing to do is a ROLLBACK (which may return an error result which you can ignore)." ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
