locked
multiple client per client database and hierarchical sync RRS feed

  • Question

  • How to handle these scenarios?

    In a hub-and-spoke configuration, how to handle these scenarios?:

    Conditions:
    A hub-spoke configuration. There exist users and accounts in the client, while for the server the only filtering criteria is the account. The server will use the AccountId to find the set of data that should be sent to the client. Now, the client will have internal policy to locally filter what data is presented to the user.


    Questions
    1. Having a single client database. One client logs in under one account and syncs. After finished, other client (or same) logs in under another account. If the two accounts in the server ever had some data shared, meanining, if they are in anyway linked to a given record in a given table, will it be sent to the client twice? Will the sync process try to write again the shared data?

    2. I understand that the client has to have an anchor table and the sync user table (guid, from the SqlExpress sample). How can this be extended to handle my scenario?

    3. The database model used in the server is very similar to that of the client. In both cases there are 100+ tables, out of them 80% account dependent. I am interested only in transferring to the client the non-dependent tables (lookup) and from the dependent ones only the data that is linked to the account. Is modifying the syncadapters in the server the only way to get the filtered data? I ask because, although the Db has a good design, it is going to be expensive to find all the related data in each session, and even more, considering that many tables are more than three levels down in the hierarchy from the accounts table, so many queries will include joins between four or more tables.

    4. More about #3. Because there's many relationships on the tables, there's proper sequence to get data from and to insert data to the database tables. Is this taken care of automatically by the MSF, independently of the order of creation of the syncAdapters? or do I need to explicitly establish the sequence in order to get a consistent behavior? (e.g. dont want to sync first a table that requieres data that still does not exist in another one)..

    Thanks!

     





    • Edited by mape1082 Friday, October 30, 2009 1:44 PM fixing formatting
    Friday, October 30, 2009 12:46 AM

Answers

  • Good questions.

    unfortunately the major issue you described here, i.e. to have same database to support mutiple subset ( filtered by accout ) of data is not supported with the current released versions. a few things you can do with the tables with filters:
    1. reinit if the user changes. this is probably the easiest way to do however the reinit could take long time if you data is large. with this approach, you will also need to put the look-up tables in seperated db to avoid unnecessary reinit of them.

    2. put possilbe subset of data in one db, i.e. if user1 and user2 will be likely switch, you can put them in one db so both data were sync-ed and you deal with the switch in the client side logic.

    3. other approaches, this may vary from case to case.

    regarding with the table ordering to deal with RI. you will need to carefuly order them when adding the syncAdapters for them, the sync services take the orders in the syncAdapters collection for inserts and updates, and reversed order for deletes.

    hope this helps.

    thanks
    Yunwen

    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by mape1082 Wednesday, November 18, 2009 9:01 PM
    Wednesday, November 18, 2009 4:56 PM
    Moderator

All replies

  • Good questions.

    unfortunately the major issue you described here, i.e. to have same database to support mutiple subset ( filtered by accout ) of data is not supported with the current released versions. a few things you can do with the tables with filters:
    1. reinit if the user changes. this is probably the easiest way to do however the reinit could take long time if you data is large. with this approach, you will also need to put the look-up tables in seperated db to avoid unnecessary reinit of them.

    2. put possilbe subset of data in one db, i.e. if user1 and user2 will be likely switch, you can put them in one db so both data were sync-ed and you deal with the switch in the client side logic.

    3. other approaches, this may vary from case to case.

    regarding with the table ordering to deal with RI. you will need to carefuly order them when adding the syncAdapters for them, the sync services take the orders in the syncAdapters collection for inserts and updates, and reversed order for deletes.

    hope this helps.

    thanks
    Yunwen

    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by mape1082 Wednesday, November 18, 2009 9:01 PM
    Wednesday, November 18, 2009 4:56 PM
    Moderator
  • Hi Yunwen Bi,

    For you #3 answer: I think this is not desirable! Infact, we all know that relation is an important part of database. Sync framework do not care any confict which invole in relation, that mean, the developer have to do that work all the time! This is a very painful task and the sync framework itself is useless!

    Some thought.
    Dong Luu

    Saturday, November 21, 2009 11:51 AM
  • Hi Dong,

    Actually I think I probably didnt make it super clear with my previous post. Sync Framework DOES care a lot about conflicts involing in RIs. it is all about complexity and simplicity and focusing on major scenarios. consider that if building the order of tables at the runtime to take care of the RIs among all the tables being sync-ed. the sync run time will need to get the schema for EACH sync ( as the RI could be changed ), this will introudce an extra burden to the back end sql server. that is how the order of tables was introdued so users can take the desired action/solutions based on the scenarios.

    Yes, I agree this will cause a bit more for sync application developers. but this is also give developers the flixibility to own this chart.

    Hope this explains.

    thanks
    Yunwen
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, November 25, 2009 9:53 PM
    Moderator