Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Sync Framework without Unique Identifier RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    is it posssibe to sync without Unique Identifier field. 

    i am ussing INT datatype to all the primary key field insted of Unique Identifier field. is it possible to implement sync Framework??

    I have tried same ListManager sample with Int Data type but its not working...

    thanks

    Amila

    Tuesday, February 21, 2012 1:13 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    the primary key is not required to be a uniqueidentifier.

    see: Selecting an Appropriate Primary Key for a Distributed Environment

    Tuesday, February 21, 2012 1:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    hi thanks for your reply.. i have done with INT data type..

    but n my business logic i have to use Unique Identifier..

    Thanks a lot 

    Saturday, February 25, 2012 6:01 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    *Late* but I wanted to give my take on how I selected PK's:

    1. If starting from scratch, always use Guid/unique identifier. Don't even bother with identity. Look into RowGuid and newsequentialid() to act as identity columns but in Guid format.
    2. If one peer/server is to be the master of a given set of data, that is fine as an identity/int. This is typically DownloadOnly syncs.
    3. If you're doing UploadOnly where multiple clients are sending to a master server table, unique identifier is your friend here. If you use identity you can have 5 clients all start with id 1 and be in a world of hurt. There are suggestions to increment the seed with a prefix but you would have to give more room than you probably have to make sure clients don't conflict. If the data you're using to sync has a tendency to be dropped and readded, you're going to run out of room real quick.
    4. One caveat mentioned is to not use timestamp at all as a primary or composite key as the _tracking tables already have one and use bigint for the rest. So far this seems to be the only real schema restriction.

    Of course I'm still very green and I'm learning by fire working through some issues but I learned the hard way on picking the right column. I'm one of those people that chooses the path of least resistance and luckily I can choose #1 and never really have to think about it again.

    Thursday, April 12, 2012 1:34 AM