locked
Capturing and using new anchor value on client RRS feed

  • Question

  •  

    Situation

     

    n-tier implementation of the sync framework.

     

    Very large table of tasks that are associated with projects so need to be able to sync based on a subset of projects (not too hard).

     

    Multiple users on the same machine and each user has different projects. (harder)

     

    Problem:

    Users are assigned projects, and when they sync, I only want to download the tasks from the projects to which they are assigned.  Stored procedures ensure the returned data is correct, but since the anchor values are stored by table on the client, there is a problem when a different user tries to sync.

     

    Example:

    (all anchor values in the following example are made up).

     

    User 1 syncs on Monday (client task table gets the new anchor of 272DA).  After her sync, changes are made to the tasks table on the server which impacts tasks for both user 1 and user 2. 

     

    User 2 syncs on same device on Tuesday (client task table gets the new anchor of 27322) .  User 2 does not have the same projects as user 1, so only tasks associated with his projects were downloaded.

     

    Now User 1 comes back to device on Wed, and syncs.  Since the table was synced on Tues, the anchor that is sent as the "old" starting point is 27322.  Any changes made on Monday for User1's tasks will not be read from the server. 

     

    Questions:

    I need to be able to store the anchor that was returned by any given sync and store it on the device by user/table and then override the "old" starting point with this value on subsequent syncs.  I see a property on the clientSyncProvider for SetTableRecievedAnchor and assume that I can override here, but wanted to be sure this was the right place to do it.  Searches on msdn did not turn up and references to this method.

     

    Second, I have been trying to convert the returned anchor from GetTableReceivedAnchor method (again on the client sync provider), but can't seem to get it into a sensible value (again searches on MSDN come up with nothing).  Since the anchor is a byte array, I am converting it wih BitConverter.  ToInt32 gives a really low number, and ToInt64 gives a very long negative number.  What's the secret code for getting this into a format that I can store and ultimatly use to override the starting anchor on subsequent syncs?

     

    Thanks.

    • Moved by Max Wang_1983 Friday, April 22, 2011 9:05 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Wednesday, January 9, 2008 10:44 PM

All replies

  • Alan,

     

    In my opinion each user should have his or her own cache (sqlce database). This will simplify it a lot for you. That's how Outlook works for example.

     

    There is no secret code really Smile, the anchor is serialized before it is sent to the client. You might find this demo project interesting.

     

    Thanks

    Saturday, January 12, 2008 7:53 PM
  • The example I gave is a simplified version of my reality.  A seperate cache for each user is an unworkable solution in my case.  While having separate stores for each user might be possible, the storage requriements would be problematic and there is a lot of shared database data that is not user specific.  I would hate to design something with loads of unneeded duplication.

     

    I was able to work out a solution that uses a table in the client database that stores when each user syncs via a datetime field.  This data is used to control what is retrieved from the server.

     

    My original intention was to try to utilize as much of the delivered functionality of the framework as possible, however the timestamp methodology was not robust enough to meet my needs so I had to go a different route.

     

    I was very pleased to (eventually) discover that the framework is very flexiable and could easily accomodate my needs.  The biggest hurdle was that I had to discover much of this flexability via trial and error, and not from documention.  Ah, the perils of early adaption.

    Sunday, January 13, 2008 5:14 AM
  • Hi,

     

    I am currently struggling with a very similar scenario and have also looked into the anchor managing functions.

     

    I would appreciate very much if you could elaborate a bit about your solution - I desperately need some inspiration!

     

     

    Thanks beforehand,

     

    Morten

    Friday, May 9, 2008 12:44 PM