Isaac Raway wrote:
I am looking at a design that will require syncing a disconnected SQLite DB
file on client's machines to a central server. The version of the DB on the
server will also be modified periodically, so there is a chance that new
records will be created in either and also updated. Conflicts therefore are
an issue. I am looking at generic methods for handling the deltas between
BLOBs I have in my DB, and I think that's within reach.
What I'm worried about is just the logistics of either 1) importing all
user's data to a single DB somehow or 2) managing several DB files from
clients automatically. Has anyone does this kind of syncing? I realize I'm
somewhat light on details, but I'm not really even sure exactly what this
system will need to do: it's more of a framework really.
At any rate, anyone have experience syncing SQLite DB files?
One method is to use rsync to synchronize the files. That takes care of
deltas etc.
We keep Sqlite DBs sync'd by maintaining a "stale" counter using
triggers and having the remote DB sync itself when it decides that it is
stale. We use an XML based transaction transmission to perform the
synchronization. The theory of our method is that the sync'd DB could
be any RDBMS, not necessarily Sqlite or even an SQL driven DB.
This last method involves some extra overhead. A DB access includes a
communication with the central DB to get the current status. The rsync
method is less overhead, but does not maintain real time synschronization.
Our real time method is used to maintain a distributed database with
good local performance and which is tolerant of network disruptions. A
network failure does not stop production, it merely degrades the quality
temporarily.
A word of caution. Keeping the DB's sync'd in real time involves a lot
of logic and is not a trivial exercise.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
