If you are using something like an log system it would be better in this way, but in apps like an shop what wouldn't be so great. (thinking about ebay with the bets and such..)
But the idea itself is nice. Am 02.01.2010, 00:14 Uhr, schrieb Olaf Schmidt <s...@online.de>: > > "Artur Reilin" <sql...@yuedream.de> schrieb im > Newsbeitrag news:op.u5vlqcps1pq...@rear... > >> But that means, if there is a power off or an system crash, >> your data which you send at this moment, goes nirvana. > > Yep, as I wrote at the end of my post: > "...in case of an unexpected Close of the App (due to > whatever reason), you will lose only the new data which > was gathered within the last timer-interval." > > The Timer-interval in question should therefore not be > too large - also with regards to "palpable App-Blocking" > in the continously (timer-triggered) "syncing Events" ... but also > not too small, to achieve the expected "performance effect" - > so, at least "more than only one single new log-record" should > be gathered (on average) within the interval, to work with a > somewhat better write-efficiency. > > Would require some experimenting first, which timer-interval > works best (depends somewhat on the frequency and size of > the incoming new data-records, but also on the underlying > storage-media, the DB is hosted on - be it flash-based media, > as USB-sticks for example - or "real Hard-Disks"). > > Olaf Schmidt > > > > _______________________________________________ > 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
