locked
Metadata stored in external database RRS feed

  • Question

  • We are trying to leverage Sync Framework 2.1 to synchronize a source database with several destination databases. We are currently facing 2 challenges:

    1. We'd like to keep both, the source and destination dbs as clean as possible. Hence, we want to use an external metadata database  to be used during the synchronization session. Has anyone implemented something similar? Can you enumerate the classes you have leveraged from the framework to accomplish this?
    2. We do not require InLine Change Tracking, so we are looking at implementing the Asynchronous one. Is there anything already built in for this or should we also implement it?

    Thanks very much for your help!

    Friday, November 12, 2010 2:14 PM

Answers

  • Hello,

    To answer your questions,

    1. We don't support decoupling of metadata and user data in separate databases. If you are worried about cleanliness, the tables are separate. The generated stored proc and triggers are generated with specific format. Furthermore, deprovisioning wipes out all generated objects and leaves your database with just user data.

    2. I am not exactly sure what you mean by asynchronous change tracking here. Tracking metadata currently happens synchronously as far as I know.

    Hope this answers some quesitons for you.

    Thanks,

    Patrick

    • Marked as answer by capsicums Monday, November 15, 2010 4:52 AM
    Friday, November 12, 2010 7:02 PM

All replies

  • Hello,

    To answer your questions,

    1. We don't support decoupling of metadata and user data in separate databases. If you are worried about cleanliness, the tables are separate. The generated stored proc and triggers are generated with specific format. Furthermore, deprovisioning wipes out all generated objects and leaves your database with just user data.

    2. I am not exactly sure what you mean by asynchronous change tracking here. Tracking metadata currently happens synchronously as far as I know.

    Hope this answers some quesitons for you.

    Thanks,

    Patrick

    • Marked as answer by capsicums Monday, November 15, 2010 4:52 AM
    Friday, November 12, 2010 7:02 PM
  • Thanks Patrick! Yes, we wanted to avoid setting up triggers on our destination dbs for both, cleanliness and performance reasons. The asynchronous term was extracted from this article http://msdn.microsoft.com/en-us/sync/bb821992.aspx. The reason why we looked at this possibility is because we do not need live synching at this moment, so running a separate process that would detect changes when required seemed more appropiate. It would also allow us to get rid of triggers in the destination db.

    The article refers to the possibility of implementing 2 types of versioning, inline and asynch. So we were wondering if someone had taken the asynch approach.

    "Asynchronous tracking: In this method, there is an external process that runs and scans for changes. Any updates found are added to the version information. This process may be part of a scheduled process or it may be executed prior to synchronization. This process is typically used when there are no internal mechanisms to automatically update version information when items are updated (such as when there is no way to inject logic in the update pipeline). A common way to check for changes is to store the state of an item and compare that it to its current state. For example, it might check to see if the last-write-time or file size had changed since the last update."

     

    Regards,

    Diego

    Friday, November 12, 2010 8:47 PM