locked
Indentity Key Problem RRS feed

  • Question

  • I am syncing a table called TaskInfo. It has an identity key column called TaskNo. We can successfully sync this table. However, we tried a scenario.

    • Device A) creates a task with TaskNo 1
    • Sync Occurs
    • TaskInfo with TaskNo 1 is created on the central database
    • Device B) creates a task with TaskNo 1
    • Sync occurs
    • Conflict occurrs

    Why is this? The key created on the mobile client is an artificial number; it should not be transferred on to the central database server. We assumed that the mobile device's task numbers would be different to those on the central server because otherwise we are just going to get constant conflicts. What is a strategy to avoid these conflicts? Do we have to have to have separate key spaces for each device?

     

    How do we get around this? We have to deliver a prototype very soon and if we are getting constant conflicts, we are going to be completey stuffed.

     

    Christian

    • Moved by Max Wang_1983 Friday, April 22, 2011 6:11 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Tuesday, August 5, 2008 5:33 AM

Answers

All replies

  • Hi Christian,

     

    the conflict you are seeing is actually expected. the sync service currently doesn't support ID range management so you will need to handle this in your own logic at the application level. the following two threads already discussed this and you can refer them for details and the solutions for it.

    http://forums.microsoft.com/Sync/ShowPost.aspx?PostID=1335337&SiteID=75
    http://forums.microsoft.com/Sync/ShowPost.aspx?PostID=3541921&SiteID=75

     

    thanks

    Yunwen

     

    Tuesday, August 5, 2008 5:45 AM
    Moderator
  • Thanks. Actually working with GUIDs is much better than working with Identity Columns because you can know the value of the primary key before it is inserted in to the database. Finally a solution to this age-old problem that has plagued programmers who work with both Oracle and Sql Server. This is an answer to Oracle's sequence table architecture.

    Thursday, August 21, 2008 1:06 AM