Also are they using Time Machine on a networked drive?
Whilst Time Machine was not supposed to work across networks, people
have made it work using 3rd party software. I know because we tried it
for a laugh and abandoned it (and Time Machine) as it was wholly
unreliable.
However I think the WAL commit (or uncommit) is a more likely scenario.
Rob
On 12 Dec 2018, at 15:00, R Smith wrote:
On 2018/12/12 4:48 PM, Richard Hipp wrote:
On 12/11/18, Daniel Alm <dan...@timingapp.com> wrote:
Any suggestions on what could be the culprit or what else I could
try
besides downgrading all the way to SQLite 3.21 would be appreciated.
Nothing about SQLite has changed that should make a difference here.
Do you know if the corruption is occurring when TimeMachine makes its
backup, or is occurring when the backed up database is restored? Can
you capture some unrestored TimeMachine backups to see if they are
corrupt?
My best guess here is that TimeMachine somehow captures the sqlite DB
files a few milliseconds apart "sometimes" so that a journal file that
has just been committed is in the TimeMachine backup captured still in
its uncommitted state while the DB itself is in the committed state
already (or perhaps vice-versa).
This theory however makes no sense unless either the journal mode in
SQLite has changed (either via update or pragma change by user), or
TimeMachine itself has changed its ways since when things used to work
correctly.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
