none
Wrong ClientID reported in ApplyChangeFailed event (ApplyChangeFailedEventArgs args.Session.ClientID) RRS feed

  • Question

  • SyncFramework 2.1; WCF; Client is a PC

    In the ApplyChangeFailed event in the WCF server-side code, args.Session.ClientID (where args is a ApplyChangeFailedEventArgs) reports a different value than the ClientID I create on the Client and feed to the client's SyncProvider with this code:

    clientSyncProvider.ClientId =

    new Guid(DeviceConfig.ClientID);

    //DeviceConfig retrieves a GUID stored in the SqlCe .sdf file

     

     

    I would expect (maybe wrongly) that the ClientID would be the same ... any idea why it's not?

    If it is not supposed to be ... how can I retrieve the ClientID specified on the client, at the server?

    (sure would be helpful in logging errors to know which client is causing the errors!)

    Thanks!

     
    Wednesday, April 6, 2011 8:26 PM

Answers

  • you should be OK to set the ClientID at the client provider during the runTime. this value will not be persisted to disk as it was mentioned in previous posts, however, this ID should be valid for this sync session or till the ClientProvider was reset. and the value should be in the e.Session.ClientId ( of the ApplyChangeFailed event arg ).

    Please ensure your DeviceConfig.ClientID is not Guid empty. eitherwise, the sync agent will pick up a newID for the session which is random.

    if this is not you observed, could please enable the trace and share out the trace file so we can see what would be wrong ? it surely shoud not be random for sure.

    to your second question: unfortunately it is NO. everytime the SDF file was moved to a new box, it will be considered a new client hence getting a new ID.

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, April 20, 2011 11:35 PM
    Moderator

All replies

  • can you try to not set the client id and see whether they are consistent each time?
    Friday, April 8, 2011 12:00 AM
    Answerer
  • Before I added the line it was consistent for any particular client (consistent for each time the client synchronizes) ... it's just not the value I want or defined; however, the GUID is different for different clients.

    Friday, April 8, 2011 12:15 PM
  • So looks like after you set it on a client, then it become inconsistent.

    Are those unexpected guid for other client or they are totally random?

    If they falls into the range of your prepared client ids, you can check whether your logic to assign the client Id is always consistent.

    If it's not, maybe it's a bug in the sync code.

     

     

    Friday, April 8, 2011 5:52 PM
    Answerer
  • The GUIDs are not for other clients ... so far they appear to be random.

    Of note: when I create a SqlCe .sdf file, SyncFramework automatically associates a GUID with the ClientID field for that instance of the file (apparently stores it somewhere in the file) - a sync session uses this ID by default ... the problem is that when I copy the file to another machine, the ClientID changes (this is in and of itself unexpected) ... so I cannot use that ClientID to reliably identify the file.  Therefore, when the file is originally created and a ClientID is generated by SyncFx, I store the ID in a field of one of my tables so that when the SyncFx-generated ClientID changes ... I still know what it was originally.  This requires that I feed my stored ID into the sync session instead of letting the sync session default to the one that changes when the file is copied.

    All that to say ... I am wondering if the ApplyChangeFailed is defaulting to the ClientID that SyncFX created instead of the ClientID that I store and feed to the session.

    Friday, April 8, 2011 6:20 PM
  • If the file is copied to another machine, the clientID of this “client” will be changed --- it will be treated as a separated/new client. The clientID should be readonly and reset will not be persisted.

    Monday, April 11, 2011 5:31 PM
    Answerer
  • Thanks ... the behavior you describe is exactly what I figured out ... though I compensated for the behavior by storing the ClientID in a table ... how would I instead go about making it "readonly"?

    I still have the issue that prompted this thread to deal with ...

    • Proposed as answer by Sameer[MSFT] Monday, April 11, 2011 9:11 PM
    • Unproposed as answer by Sameer[MSFT] Monday, April 11, 2011 9:12 PM
    Monday, April 11, 2011 7:13 PM
  • Could you please elaborate on your scenario and requirements?  Why do you still want to treat it as the “same” client after copying the CE file to a different machine? By design, SyncFX will treat this as a new client. Data wise, the new client will sync and converge.


    Ann Tang
    Tuesday, April 12, 2011 10:54 PM
  • The process is this: a user "checks out" their .sdf file and stores it on a particular device to do their work.  When they return to the office, they "check in" their .sdf file.  The .sdf may be on a separate device every day - each time generating a new ClientID.

    I use the ClientID to tie system records in the backend SQL database to the client who generated them.  One simple example is that I have a table where I store the date/time and results of client syncs.  I use the ClientID to uniquely identify a particular SqlCe .sdf file - if the ClientID changes every time the file moves I cannot query all syncs for a particular user.

    My solution is to persist the original ClientID by storing it in a table ... I then use my static ClientID instead of the clientSyncProvider.ClientId to identify the client.  I'm not sure this command has any effect:  clientSyncProvider.ClientId = new Guid(DeviceConfig.ClientID);.

    This seems to work well everywhere (I pass my ClientID to SQL parameters for filters etc.) ... except the ApplyChangeFailed event on the server.  The ClientID reported by args.Session.ClientID (where args is a ApplyChangeFailedEventArgs) is not the ClientID I save in my database and pass to the session - I suspect it may be the last ClientID the .sdf client automatically generated when the file was last moved (to the current device).

    What I am ultimately trying to accomplish is to tie records I store for conflicts generated during the sync to the ClientID that generated them ...

    Options?:

    • Can I pass my ClientID to the session as I am attemting to do in the code in paragraph 2?
    • Can I prevent a .sdf file from generating a new ClientID when it is copied (or as someone suggested above, prevent it from persisting)

     

    Wednesday, April 13, 2011 12:47 PM
  • you should be OK to set the ClientID at the client provider during the runTime. this value will not be persisted to disk as it was mentioned in previous posts, however, this ID should be valid for this sync session or till the ClientProvider was reset. and the value should be in the e.Session.ClientId ( of the ApplyChangeFailed event arg ).

    Please ensure your DeviceConfig.ClientID is not Guid empty. eitherwise, the sync agent will pick up a newID for the session which is random.

    if this is not you observed, could please enable the trace and share out the trace file so we can see what would be wrong ? it surely shoud not be random for sure.

    to your second question: unfortunately it is NO. everytime the SDF file was moved to a new box, it will be considered a new client hence getting a new ID.

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, April 20, 2011 11:35 PM
    Moderator