"D. Richard Hipp" said...
SQLite version 3.7.16.2 is now available on the SQLite website
http://www.sqlite.org/
The 3.7.16.2 patch release contains a two-character change in the Windows
OS interface that fixes a long-standing race condition that could lead to
database corruption. This bug has apparently existed in the code every
since version 3.0.0. The corruption opportunity arises as follows:
(1) A process crashes or is killed while in the middle of a COMMIT,
leaving behind a hot journal that needs to be recovered.
(2) Two or more new processes attach to the database and try to run the
recovery at the same time.
If step (2) happens on a fast multi-core machine, and you are unlucky,
then the xCheckReservedLock() method of the OS interface object might
return a false positive result, deceiving one of processes into thinking
that the recovery had already been accomplished and causing that process
to delete the rollback journal and thereby corrupting the database.
Note that this flaw was present in the Windows interface only. The
unix/posix OS interface works correctly. For unix, the only thing that
has changed between version 3.7.16.1 and 3.7.16.2 is the version number.
We have an application that uses a shared SQLite file and many times during
the day multiple PCs connect to that file at the same time. Some to get
data others to COMMIT data. Can this problem also from a DB file shared via
Windows Shared folder with connection from two different PC? We had a mayor
problem, one day where we lost all of the data updates. We had to recover
the previous night file and re-enter the lost data. So, I am wondering if
this was the cause. Thanks.
josé
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
