MSF Working with Other VS Tools RRS feed

  • Question

  • Hello Liam,


    Thanks again as this information will greatly help in the design of the application. I just want to make sure that I make the correct decisions in selecting the appropriate tools for developing the CRM application.


    To answer your question on the size of the database on the local machine, I am not really sure how big it can get. But does the Sync framework automatically delete the changes from the source database after the sync? Just to give you some insight, below are some of the requirements for the project:


    1. Ability to work offline (MSF)
    2. Reporting (MS Reporting Services)
    3. Workflow (MS Windows Workflow Foundation Framework & WCF)
    4. Pull relevant data from other internal applications (SOA – Web Services)

    Do you think the technologies that I have described above fit together? If a workflow job is initiated and the user goes offline and completes the task, can Windows Workflow Framework work with MSF?


    Also from my understanding, MSF is a pull system where the user application needs to request information from the core database. Is there a way to have a service running on the core system that automatically pushes information to all the local user databases in addition to the pull mechanism?


    I do have one other basic question. In MS SQL Server 2008, it has built in track changes capability which can be leveraged by MSF. But lets say I go with SQL Server Compact (local) and SQL Server 2000 (core). Do you have to explicitly create triggers on both databases? I saw an example online for MSF and in it the presenter created a Local Database Cache and selected a database from the core SQL Server which the created a local cache in the users local project. Then the person made a change to data on the core system and created a button to sync the local app. When the button is clicked, a sync agent syncs both these databases. But there was no mention of triggers.



    Gaurav Bhasin

    • Moved by Max Wang_1983 Friday, April 22, 2011 9:07 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Thursday, November 8, 2007 4:17 PM


  • Hi Gaurav,


    When you ask about deleting changes from the source database after sync you bring up a really good question.  The ability to keep change information differs based on the type of solution you are looking to build. 


    If you were building a Peer-to-Peer solution, keeping old change data for longer periods of time is more important because you don't necessarily know that all the peers have your changes. 

    In your case, you are are looking to build an offline (hub-and-spoke) type solution using the Sync Services for ADO.NET part of the Microsoft Sync Framework.  So in your solution it will be important to keep changes in the server (hub) database until you are confident that all of the clients (spokes) have received those changes.  In any non-SQL Server 2008 database, this is a manual process or at least something you have to set up yourself to automate the cleanup of the chane tables.  Now in SQL Server 2008 we have automatic change tracking which is great because: 

    • No schema changes are required to be able to track changes
    • Triggers are not required for tracking changes, which means that tracking changes has far less of an impact on the server.
    • In certain cases, the DML overhead associated with trigger based change tracking can be 400% greater than that of SQL Server 2008 change tracking. The overhead of enabling SQL Server 2008 change tracking is similar to the overhead of maintaining a second index.
    • All of the logic for tracking changes is internal to the SQL Server engine and as such reduces the complexity for setting up this type of system.
    • Data consistency issues associated with long running transactions are no longer an issue.
      Includes integrated database administration feature such as Dynamic Management Views and Security
    • There is still the issue of cleaning up data changes, but luckily SQL Server 2008 Change tracking has customizable retention thresholds which are used to maintain this change data and automatically clean up old data.

    Now, on the client side it is a different story.  As soon as you know the server has received your changes, you are free to clean up the old changes.


    As to your questions about the requirements for the project, other than for #1 and #4 which we can definitely help with, I have to admit I do not have much experience with those technologies so I can not comment other than to say that I see no reason why you can not take advantage of those technologies.


    You are also correct that the Microsoft Sync Framework is a pull technology.  In order to push from the server side, usually what people will implement is a push-pull type model.  What this means is that in the server you create some sort of trigger based on an event of your choosing (e.g., inventory gets below 10 units).  This causes a trigger which sends a notification to one or more mobile users.  Maybe that is an SMS message or an email.  On the device there is some sort of listener tool which is monitoring the SMS or Email inbox for these notifications.  When it receives that message it parses it and initiates a background synchronization to the server.  To the user it looks as though the server is pushing information when in fact the server is just sending notifications to the device to initiate a pull sync.  Some other things that you might want to consider if you are using Exchange is to take advantage of the existing direct push features built into Exchange server.  You might want to check out the following post for more information on this topic here: 


    As to your final questions, yes if you use SQL Server 2000 (rather than SQL Server 2008 with Change Tracking) then you will need to implement some additional triggers and columns for doing synchronization.  I am not sure of the demo that you saw so I am not sure if the demo automatically added these triggers and columns or if it simply used a snapshot synchronization approach which basically does a select * from table during every synchronization.  Obviously this is very inneficient in a mobile environment to re-sync the entire table during every synchronization which is exactly why you either need these triggers and columns in SQL Server 2000 or to enable Change Tracking in SQL Server 2008.


    I hope I have helped to answer all of your questions,


    Thursday, November 8, 2007 5:51 PM