Location5 (data archiving and history recovery)
- Last UpdatedDec 18, 2025
- 2 minute read
The Location5 attribute configures exception reporting and the handling of events with duplicate timestamps. For output points, it configures how events are recovered from Data Archive to an RDBMS. For details about recovery, see Learn how to recover historical data.
Location5 is relevant only for data that is Out of Order. The RDBMS interface does not treat Historical Data as Out of Order unless the query results are ordered in descending order by timestamp. In all other cases, Historical Data is updated in sequence, and Location5 is disregarded.
Tags and queries that include PI annotations bypass exception reporting and are written directly to the archive, regardless of their Location5 attribute setting.
The interface also executes recovery in real-time mode during startup to guarantee the capture of any events that took place while it was offline.
Input points
To configure handling of out-of-order data for an input point, set Location5 as follows:
|
Value |
Description |
|---|---|
|
0 |
Enable standard exception reporting and out-of- order data handling for a tag. If the archive already contains an event with the same time- stamp as the incoming event, the archived event is not replaced with the incoming event. |
|
1 |
Disable exception handling and send all incoming values to the snapshot. For out-of-order data, existing events are replaced and new events are added. |
|
2 |
Archive all incoming out-of-order values. Be aware that if you set Location5 to 2, there can be multiple events with the same timestamp. |
|
3 |
For the tag distribution strategy, forward to PI only newer events than PI snapshot. |
|
4 |
Enables the full sync mode. See Full synchronization of time series from RDB tables to PI Data Archive for additional information. |