On 9/21/15, Hugues Bruant <hugues at aerofs.com> wrote: > 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=?;
My guess is that the WHERE clause matches no rows. So it isn't silently failing, it is doing exactly what it is suppose to do: Update only those rows you have specified. > > 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. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp drh at sqlite.org
