Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Status No status
Product PI Interfaces
Created by Guest
Created on Aug 18, 2022

New start-up parameter /SYNC_TIME defining a floating-window during which the interface will keep a RDB table in sync with PI data archive

The new RDBMSPI param:  /SYNC_TIME=rel_start_time,rel_end_time   for instance /SYNC_TIME=*-6h,*+1h When set, the interface: - after each execution of a query, which shall have the same "floating" window in its WHERE clause; for instance: SELECT time, value, status FROM table1 WHERE time BETWEEN GETDATE()-6  AND GETDATE()+1; reads events for this tag from the PI data archive (for the interval defined by /SYNC_TIME) and compares timestamps from both sets. The "master" is the set from the rel. database; that is, if in the set taken from PI, there are timestamps, which were not returned from RDB, they are deleted (in PI data archive), values at the same timestamps are overwritten (updated in PI) and new values are added. This feature only applies for single-strategy tags. Note: This was previously Enhancement 125216.
  • Attach files
  • Guest
    Reply
    |
    Aug 18, 2022
    We would also like this. Ideally a linked table could be used to keep the data to the freshest level, however Linked Tables cannot handle AF analysis for heavy usage. We have manual entries and values being restated or coded for a different time and ending up with extra "wrong" data in PI that. An automated compare and removal of these stale values from the PI tag would be a much smoother process if part of base functionality.