locked
Inconsistency of data when table filters are used RRS feed

  • Question

  • Hi, 
      I´ve implemented a data base synchronizer using Microsoft Sync Framework 2.0. The providers i use are SqlSyncProviders, and the data base i synchronize was created using SQL Express 2008. The scope created for each user that synchronizes contains filters on many tables which are causing the symptom described below... 
    Let´s assume the following scenario:
        - The scope of user A contains a filter on table Account. This filter specifies that user A will only synchronize those accounts that belong to him. So, user A will have in his local data base only the accounts that belong to him.
        - Then, let´s suppose that other person (let´s say the boss of A) decides to assign, to user B, one of those accounts that where assigned to A. So, that account will be now assigned to B in the Server data base. 
        - When A synchronizes next time, that account will not be updated in his local database because it does not fit the defined filter anymore. As a result, that account will be assigned to B in the server data base, and will still be assigned to A in the local data base of user A.

    What i would expect is that the account that does not belong to A anymore could synchronize at least once in the local database of A, and possibly make it disappear after discovering that it does not fit the filter anymore.
    So, is there a way in sync framework to overcome with this scenario?

    Thanks in advance!
    Paola
    Friday, March 5, 2010 7:07 PM

Answers

  • Hey Paola,

    This is a change "moved out of the scope " scenario. Unfortunately, Sync Framework doesn’t have out-of–box support for this currently. However, we do recognize this is a common scenario and will look into this in future release.

     

    Thanks,

    Ann


    Ann Tang
    Saturday, March 6, 2010 12:35 AM

All replies

  • Hey Paola,

    This is a change "moved out of the scope " scenario. Unfortunately, Sync Framework doesn’t have out-of–box support for this currently. However, we do recognize this is a common scenario and will look into this in future release.

     

    Thanks,

    Ann


    Ann Tang
    Saturday, March 6, 2010 12:35 AM
  • 1. Ann is right.
    2. A possible work around is on the sync application level.  Assume changes are from device A and syncing to the server.  Before Changes applied to the server, exam each data row.  If the row on the server does not belong to A any more, please skip this change.  After submitting the local changes to the server, you have the option to re-initialize the client A, if you like.

    Thanks.
    Leo Zhou ------ This posting is provided "AS IS" with no warranties, and confers no rights.
    Sunday, March 7, 2010 5:12 PM
    Answerer
  • Hi Leo, 
        First of all, thanks for the fast response! :)
        I have some questions related to the suggested work around:
    a. How I can exam if a specific row on the server still belongs to A? Should this be done by querying the server database with the filters of A during some synchronization event like OnSelectingChanges? Otherwise, Is there other way provided by Sync Framework, that lets me know if a specific row still belongs to A during synchronization?
            b. Then, after submitting the local changes to the server, what do you mean when you say "re-initialize the client A"? Does this mean to manually remove the local data base and to create it from scratch, or there is other way provided by sync framework that lets me perform this task? Summarizing, what i would like to implement is a way to make all records that don´t belong to A anymore disappear from A´s local data base. 

    Thanks in advance, 
    Paola
    Tuesday, March 9, 2010 1:50 PM
  • Paola,

    if you can get hold of the new filter for the client, you can try disabling the delete trigger on the table (so the deletes dont get synched), then delete all rows from the local table that do not satisfy the filter, then re-enable the trigger. optionally, you can delete the corresponding rows in the tracking table as well.
    Tuesday, March 9, 2010 4:08 PM