yes indeed the "journal tweaking" would work solely for this special file case, comparing local and remote that's how for instance git works like many other sync software, I don't know the API but is the box thing notify you "on start transaction" then "on close", if not it sucks ?
On Tue, Jul 15, 2014 at 6:53 AM, mm.w <0xcafef...@gmail.com> wrote: > ok sorry, I did not red all thru, may you simply sha1 local and remote ? > if != commit again > > > On Tue, Jul 15, 2014 at 12:49 AM, Simon Slavin <slav...@bigfraud.org> > wrote: > >> >> On 15 Jul 2014, at 2:20am, William Drago <wdr...@suffolk.lib.ny.us> >> wrote: >> >> > The software doesn't crash on its own; I'm forcing it to crash with a >> divide-by-zero for test purposes. This doesn't happen in actual use and >> there's no reason other than a power failure for a transaction to not >> commit successfully. But that doesn't mean I shouldn't handle a failed >> transaction if it ever does happen. >> >> If all you're trying to do is spot crashes then you don't have to >> implement your own semaphore system or locking system. Use >> >> PRAGMA journal_mode = DELETE >> >> which is the default. Then you know that if a journal file exists, a >> process is in the middle of a transaction, or a process which in the middle >> of a transaction crashed. >> >> All you need to do is check to see if a file exists with the name of the >> journal file. Presumably you'd be wanting to do this when your application >> starts up, before it opens the database. >> >> Simon. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
