Hi Milan,

> Jarrod, you are completely right. In fact, in real system, I don't
> use timestamps, but BIGINT column filled with a generator. This way
> you don't miss anything, even if the system date and time is changed
> on the server (due to DST change for example).

You still have the same problem. The issue is not with using timestamps. It
is using a checkpoint (whether it be a timestamp, unique integer, version of
some sort) and doing a simple comparison with the last checkpoint value to
determine which rows need to be processed.

If you can modify the rows or use a separate table then one solution is to
delete processed rows or update a new column with a "processed" flag. That
way you don't need a checkpoint at all.

I faced these issues in my product Complete Time Tracking in which I
implemented two-way merge replication to allow users to keep a portion of
the DB locally, make changes offline, then sync their changes with central
server changes when back online. In this way each client app needed to
determine which unprocessed rows in the central database to process and due
to the potentially large number of users (thousands) I adopted a more
complex approach.

Regards,

Jarrod Hollingworth
Complete Time Tracking
http://www.complete-time-tracking.com/