Question regarding the time difference between client machine and server machine RRS feed

  • Question

  • I'm studying Sync Services for ADO.NET. I have a question that I could not find answer:

    Imagine that we have two databases, client and server, installed in separated machines.
    The anchor is generated based on server time.
    Client's rows are timestamped with client's time.

    So if client and server time are not the same, how can sync services work? How can we determine whether a row is dirty if we do not have reliable time comparison?
    • Moved by Max Wang_1983 Friday, April 22, 2011 4:47 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Thursday, September 25, 2008 10:35 AM

All replies

  • Client table holds two anchors per table. ReceivedAnchor and SentAnchor. SentAnchor is the local client tickcount and is solely used by client when uploading changes. ReceivedAnchor is the server tickcount and is communicated to the server during download phase which it will use to enumerate new changes. The client just stores the server state and so doesnt really care what it is as its used only by the server.


    Having said that, please note that once the client has a state for server stored locally and then the server changes its time zone then you would have issues.

    Thursday, September 25, 2008 6:23 PM
  • I understand that we can use client time for determine dirty rows. But consider this case:

    There are two sites, without network communication between sites. Once in a while, a user export dirty data from client machine, then drives to central database center, import data into central database. After import, server will generate a new file. This file
    will be bring back to remote site, and import into site's database.

    In this case we cannot deduce the time difference between client and server. So local time anchor is useless here. Can you folks at MSFT tell me, what must I do if I want to use Sync Service for this situation?
    Friday, September 26, 2008 1:17 AM