views:

113

answers:

1

I'm working on changes to an application to have a local data store instead of connecting directly to the database server. The client app will then sync changes both ways between the server database and its local data store. I'm trying to implement the syncing solution using Microsoft Sync Framework. To be clear there is no server application, only the database server, but there are multiple clients.

I have started implementing two classes that implement FullEnumerationSimpleSyncProvider, one called LocalSyncProvider and one called ServerSyncProvider. The LocalSyncProvider knows how to enumerate, insert, update, delete items from the local data store, and the ServerSyncProvider knows how to enumerate, insert, update, delete items from the database server. They each use the provided SqlMetadataStore and store the two metadata stores (one for the local and one for the server) on the local drive of the client. This means that each client will have its own metadata store for its local data store and its own metadata store for the server database.

Is this actually going to work, does there need to exists only one server metadata store, or do I need to be using the Sync Framework differently?

A: 

We are using a similar approach and it works as you described. The difference is that we are syncing files, not data, using the FileSyncProvider for the client and an implementation of FullEnumerationSimpleSyncProvider for the server. But we have no Sync Framework code running on the server and there are two seperate metadata files, both stored on the client.

However, I have recently come across a problem which you might want to be aware of. It seems that if the metadata stores on the client are deleted, the Sync Framework can't rebuild the metadata files without getting confused by data/files that are already on the server.

tjrobinson