The application in question is a Windows desktop application, however, storing the data is typically stored remotely for proper backup procedures. I don't have control over where the files are stored, as this is an IT decision for the companies in question, and the software allows for users to store where they want. Also, the application has mobile access in mind via Laptop, and the unit may not always be hooked into the LAN/WAN, so, copying the data locally is essential for that particular instance.
The remote file would never be directly acted on as the load mechanism would perform the backup to local, work on the local data, then when saved, the backup is done in reverse. If worse comes to worse, I just do a manual file copy to local storage and act on the data there, then, when saving, vacuum the DB then copy it back to network storage. Thanks! On Mon, Nov 12, 2012 at 2:27 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 12 Nov 2012, at 7:15pm, Stephen Chrzanowski <pontia...@gmail.com> > wrote: > > > I *KNOW* doing transactional work (Even just standard selects) can cause > > problems via a network share with SQLite due to networking `bugs` or > > whatever. My question is, does/would the backup api have the same > problem > > if I were to backup a remote file to memory or local storage, work on > data > > locally, then when needed, write back to the original location with the > > same backup mechanism? > > The backup system would work. But making any change to a database while > the backup API is being used causes its backup to restart (that's how it > works !). In other words, for the backup API to complete, no changes must > be made to the file it's backing up for a long time -- proportional to the > length of the file. > > If this happens naturally during the use of your database (you get odd > times when nothing happens for a few minutes) then your system will work. > On the other hand, if the database is under constant use (during a working > day or on a multi-user web-facing system) then your backup will never > complete until the load goes away. > > 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
