none
archive instead of update RRS feed

  • Question

  • I'm just getting started on Sync Framework, and I can use as much help as I can get.

    I have a single host db and many clients. Those clients do not need to update each other, but they do need to be able to pull selected records down, modify them, and upload them so that a series of clients can complete a work flow.

    I am looking for a way to keep a history of changes on all of records modified by each client. Each change needs to be marked by its author and time stamped. Time stamping and authoring changes is the easy part, but it seems those changes simply overwrite what was in the master db. How can I keep a history of those changes?

    Is this already provided? If not, any thoughts on how to do this?

    • Edited by Joshua Chan Monday, November 8, 2010 9:18 PM clarification
    Monday, November 8, 2010 9:17 PM

Answers

  • I don't know what your specific scenario is, hence I can't make any other constructive suggestions 

    It seems to me that you actually have a server with multiple clients and you want to just keep track of all changes made by the users, instead of having data synchronized (which is what Sync Framework is doing), so it's more a simple client-server applications than a sync ecosystem.

    The only option I think you can do this is to make the user insert a new row instead of modifying a certain existing row. Then maybe you can perform some regular cleanup of the database, where you move all "not the last" rows to some sort of an archive.

    Or you can implement this logic on the server side - have an update trigger, which will copy the old value to some table before writing the new value.

    Other option is to search for a product which does this for you.

    Hope this helps.

    Adrian

    Tuesday, November 9, 2010 1:03 AM

All replies

  • Hi, Joshua.

    Sync Framework supports the scenarios of incremental updates, and it does not (at least not out-of-the-box) support the archiving scenarios.

    If I understand correct, you want to implement something like a versioning system, correct ?

    If not, can you please ellaborate more on  the scenario you want to achieve?

     

    Adrian

    Monday, November 8, 2010 9:57 PM
  • Adrian,

     

    Yes, I want to keep a history of versions for each record modified.

    Monday, November 8, 2010 10:29 PM
  • As I said earlier, Sync Framework does not support this type of scenarios directly. The scenarios we support are to carry a change to an item from one replica to another one (where the old change will be replaced with the new one).

    On the other side, you could implement some sort of mechanism which will not update the existing row, but rather create a new one (which will be sync-ed using Sync Framework) and then have your application keep track of what is the latest version it should point to.

    But I think you will have some difficulties in handling deletes and ressurections of a deleted item. Plus, your database will grow very fast.

    Please let me know if I answered your question.

    Adrian

    Monday, November 8, 2010 10:40 PM
  • Ok, then I must come up with a contigency plan.

    If I was to run my sync through a WCF service, could I intercept the sync request server side, serialize the host db's data into an xml file that I gunzip, and insert/update the new data?

    If so, are there any examples that can get me in the ball park?

    Or, is there a better way?

    Versioning in a requirement. I am bordering on needing a source safe for this. Any ideas?

    Tuesday, November 9, 2010 12:06 AM
  • I don't know what your specific scenario is, hence I can't make any other constructive suggestions 

    It seems to me that you actually have a server with multiple clients and you want to just keep track of all changes made by the users, instead of having data synchronized (which is what Sync Framework is doing), so it's more a simple client-server applications than a sync ecosystem.

    The only option I think you can do this is to make the user insert a new row instead of modifying a certain existing row. Then maybe you can perform some regular cleanup of the database, where you move all "not the last" rows to some sort of an archive.

    Or you can implement this logic on the server side - have an update trigger, which will copy the old value to some table before writing the new value.

    Other option is to search for a product which does this for you.

    Hope this helps.

    Adrian

    Tuesday, November 9, 2010 1:03 AM
  • So, should I abandon sync framework for this application?
    Tuesday, November 9, 2010 2:21 PM
  • i think you can still use Sync Fx at least to detect the changes. for your archiving requirements on the changes made to a row, you can simply add a trigger to insert the old value to a separate archive table assuming you dont need to sync the history as well.

    Tuesday, November 9, 2010 3:45 PM
    Moderator
  • If you have multiple replicas you need to synchronize (you have a db copy (not necesary the whole db) on the client), or if you want to take your database offline (supported in v4 which right now is in CTP2) then you should use Sync Framework.

    But if your scenario is a simple client-server application then you don't actually have a sync eco-system, so there's no endpoints to synchronize.

     

    Adrian

    Tuesday, November 9, 2010 4:26 PM
  • So, a replica is a complete db copy? Really, at any given time, I would only have a subset on the cilent. There are several "down bound only" tables, and the clients need to keep that data up to date, but they will  never change that data. Perhaps, using Sync Framework would work really well for me there but not else where.

    Does that seem right?

    ( Also, this is an occasionally connected system. )

     

     

    Tuesday, November 9, 2010 8:03 PM
  • a replica is simply a copy of the data that you're synching, not necessarily the entire database since you can filter the rows that you're interested in synching. Sync Fx also supports the DownloadOnly sync direction.
    Tuesday, November 9, 2010 11:25 PM
    Moderator