Table schema: CREATE TABLE cv (cv_s integer not null, cv_o blob not null, cv_t integer not null, primary key(cv_s, cv_o));
Prepared statement: UPDATE cv SET cv_t=? where cv_s=? and cv_o=?; Most of the time the row is updated as expected but in some rare cases we've seen this statement fail silently, as in: - the row exists - the row it is not updated - step returns SQLITE_OK - changes returns 0 We've only observed this on OS X so far, with both 3.8.7 and 3.8.11.1. The new value is always exactly the old value +1 when the statement fails. The db is accessed through the sqlite-jdbc java wrapper. It is opened in WAL mode with exclusive locking. Multiple threads are sharing the connection but access is serialized by locks both in sqlite-jdbc and the application itself. sqlite was built with clang on OS X Yosemite from the amalgamation and with the following compiler flags: -O2 -fPIC -mmacosx-version-min=10.6 -fvisibility=hidden -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_THREADSAFE=2 -DSQLITE_CORE The issue does not persist across application restart which suggests something is wrong with the in-memory state but not with the db itself.
