locked
Synchronization Services Architecture RRS feed

  • Question

  • Hello, I have a few questions about Microsoft Synchronization Services for ADO.NET.

    1)      How many tables are considered too many tables to synchronize at one time or in one application?

    2)      Architecture question: I am one of three developers who are working on an application in which there will be workers updating data from 1) a continually connected network and 2) workers who have occasionally connected network access. 90% of the application is used by both types of workers. There is no logical split. Should one application be built with ADO.NET Synchronization services to run on the desktop (always connected) and the same application run on the tablet (occasionally connected)? Or should the application be split in half; one desktop app and one tablet app?

    3)      In this application the users are accustomed too an integer identity seed to identify facility buildings tracked in the application. I know GUID’s are the usual key, but it’s not easily readable or repeatable. I am going to try using an incrementing seed to create this number, but use conflict detection to repair any conflicts when duplicate numbers are generated. Is this the best approach?

     

    Your answers are greatly appreciated.

    Thank You,

    Jason
    • Moved by Max Wang_1983 Friday, April 22, 2011 8:59 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Monday, January 14, 2008 2:56 PM

Answers

  • Frankly, I haven't seen one synchronizing 1GB db so far. the original size of the db should not be a big concern ( you can create the client db without using Sync Service, e.g. get the data ported to the SSCE db ) and then using the sync service to do the incremental changes. the concern for the sync service is data transfer size, both uploading and downloading, how big the is the data change size in you case?

     

    Sorry I didn't make #2 more clear. Assmuing you have a offline client and another client is fully connected to the server. of course, you will use the sync service for the offlien client. now for the other one, you can write some ado.net app or directly connected to the sql server from the cleint to do data changes. however, if those data changes will introduce conflicts with the other client or the data already on the server (i.e. what if the admin on the server changed the data for some reason), you won't have a good way to deal with such conflicts.

     

    please refer to ms-help://MS.SynchronizationServices.v1.EN/syncdata1/html/1daf5591-d4aa-493a-81e5-6374a1e86da9.htm session in the sync service BOL for how to use the originator id instead of the GUID id.

     

    thanks

    Yunwen

    Saturday, January 19, 2008 7:31 PM
    Moderator

All replies

  • Hi Jason, those are good questions.

     

    #1. it is hard to define a line here. common guideline would be only sync the tables that has data changes, others, such as look-up tables, can be just snapshotted to the client db. the number of tables in sync also depends on your expection on performance, scalibility of the sync.

     

    #2. typical cases for the sync service is for the OOFLINE cases, but nothing prevent it from being used in a fully connected envrioment. in fact, if the changes from the fully connected client will introduce some conflicts and you need to have whatever on the server as the conflict winnder, then this client ought to be "some sort of " sync service client.

     

    #3.I am not sure I fully understand your requrements. Is the interger used to track the OFFLINE client, or some data in your case? please noticed EACH offline client has the GUID to indentify itself ( orginatorID) already in the sync sevice runtime and this can be mapped to integer. we can surely discuss this in details if this is what you need.

     

    Thanks

    yunwen

    Tuesday, January 15, 2008 11:49 PM
    Moderator
  • #1. The database that we are recreating will have ~120 tables with ~30 of those being reference tables. The current size of the old DB is ~1GB.

    Have you ever seen or heard of a scenario in sync svs. that has a large table set like this?

     

    #2. I'm a little confused about this statement. If you would elaborate I would appreciate it.

    "in fact, if the changes from the fully connected client will introduce some conflicts and you need to have whatever on the server as the conflict winnder, then this client ought to be "some sort of " sync service client."

     

    If the fully connected app is connected, it should have all of the changes that the server has. I was thinking that a form would need to syncronize before the form was loaded with data.

     

    #3. I've read a little bit about the ClientID GUID and the OriginatorID. It sounds like this can work. I need a integer value that is unique. My users will freak out if they have to look at a GUID. In my case they will see this PK because it is a reference to the most important piece of data in our DB.

    Will you tell me more or give me a link on how the OriginatorID is used?

     

    Thanks, Jason
    Thursday, January 17, 2008 2:56 PM
  • Frankly, I haven't seen one synchronizing 1GB db so far. the original size of the db should not be a big concern ( you can create the client db without using Sync Service, e.g. get the data ported to the SSCE db ) and then using the sync service to do the incremental changes. the concern for the sync service is data transfer size, both uploading and downloading, how big the is the data change size in you case?

     

    Sorry I didn't make #2 more clear. Assmuing you have a offline client and another client is fully connected to the server. of course, you will use the sync service for the offlien client. now for the other one, you can write some ado.net app or directly connected to the sql server from the cleint to do data changes. however, if those data changes will introduce conflicts with the other client or the data already on the server (i.e. what if the admin on the server changed the data for some reason), you won't have a good way to deal with such conflicts.

     

    please refer to ms-help://MS.SynchronizationServices.v1.EN/syncdata1/html/1daf5591-d4aa-493a-81e5-6374a1e86da9.htm session in the sync service BOL for how to use the originator id instead of the GUID id.

     

    thanks

    Yunwen

    Saturday, January 19, 2008 7:31 PM
    Moderator
  • The data change size should not be large, so I believe performance will not suffer greatly.

     

    Thank you for your time, Jason

     

    Tuesday, January 22, 2008 3:06 PM