Integrate Receive Timestamp Table
The receive stamp table in an integration database contains information about which captured changes have already been integrated. Because changes can be captured from more than one location, the table contains information about the 'leader' and 'trailer' location. If there is only one capture location then that location is both the leader and the trailer.
The leader location is the capture location whose changes have arrived most recently. Column leader_cap_loc contains the leaders's location name and column leader_cap_begin contains a time before which all changes captured on the leader are guaranteed to be already integrated. The trailer location is the location whose changes are oldest. Column trailer_cap_loc contains the trailer's location name and column trailer_cap_begin contains a timestamp. All changes captured on the trailer location before this time are guaranteed to be already integrated on the target machine. Receive timestamps are updated by HVR when the integrate jobs finishes running.
HVR accounts for the fact that changes have to be queued first in the capture database and then inside routing, before they are integrated. The receive stamp table is only updated if an arrival is guaranteed, so if a capture job was running at exactly the same time as an integrate job and the processes cannot detect whether a change 'caught its bus' then receive stamps are not reset. The receive stamp table is named hvr_stin_chn_loc. It is created the first time the integrate jobs run. The table also contains columns containing the date timestamps as the number of seconds since 1970 1st January GMT.
Example
Data was last moved to the hub from location dec01 at 7:00 and 9:00, from dec02 on Tuesday, from dec03 at 8:30 and from the hub to central at 9:00. For the cen location, the leader location is dec03 and the trailer location is dec02. The contents of the integrate receive timestamp table is shown in the diagram below. Note that location dec01 is not the leader because its job ran at the same time as the central job, so there is no guarantee that all data available at dec01 has arrived.
