Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Marshalling between 2 metadata stores with different Id Formats RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    I have posted before about my situation....I am trying to sync databases with different schemas, but related data. And I have written a custom provider that sucessfully does this.

    The problem I have now is that in one of the databases (call it Source)the IDs are stored 1, 2, 3 etc....per row in the table, but in the other database (call it Destination) they are stored in the name of the database in front of the Items such as A1, A2, A3. What I want to do is store Metadata in the Source with SyncIDs of 1,2,3 etc and in the Destination as SyncIDs A1,A2,A3 etc. In the GetSyncBatchParameters() method, where the Destination is asked for its Knowledge, I want to do some sort of mapping between the Destination SyncIDs and convert them to the format the Source understands.

    I really do not want to implement my own metadata store, preferring to use the default SQL Metadata Store and SQLSyncProvider one on the Client side, and only use a Custom Provider and the CE Metadata store on the Destination.

    If I knew more about what the numbers in the ReplicaKeyMap in the SyncKnowledge mean, maybe I could map them, but they are just a series of meaningless numbers to me.

    I understand what is going on at a high level, with the Tickcounts and Versions etc, but I don't know how this is represented in the SyncKnowledge.

    Any help greatly appreicated!

    Friday, July 30, 2010 3:40 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi.

    I don't think I've completely understood your scenario, but I can tell you more on ReplicaKeyMap number meaning.

    As stated here - http://msdn.microsoft.com/en-us/library/bb903620.aspx, ReplicaKeyMap represents a mapping between replica keys and replica IDs. This is done in order to optimize knowledge size. A replicaKeyMap loooks like this: (note that 0 always correspond to SELF - i.e. the Owner of the REplicaKeyMap)

    Key              ID

    0                 11111111-1111-1111-1111-111111111111

    1                 22222222-2222-2222-2222-222222222222

    this allows the knowledge to be writen as something like this:  Item1 (0:5) Item2 (1:10) Item3 (0:4; 1:10) instead of hafing the whole replicaId for all knowledge entries.

    Also, as a rule of thumb, you do not want to "touch" the knowledge yourself, as this is a tricky and most of the time dangerous issue, as you may get into an inconsistent state, when your data does not match the metadata.

     

     

    Hope this helps.

    Adrian

    Monday, August 23, 2010 6:08 PM