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.

Add a new idea Subscribe
Status No status
Product AVEVA™ PI System Access (PSA)
Categories PI SQL Client
Created by Guest
Created on Aug 23, 2022

RELATED IDEAS

Be able to use RTQP to access PI Points and Config strings (DA Directly)

Be able to use RTQP to access PI Points and Config strings (DA Directly) Use case: create a dashboard that lets me know the amount of bad data (tags) mapped to our AF. (eg. “Bad Input”, “Calc Failed”, etc) Our system has numerous tags and it is impossible to monitor them one by one. The RTQP engine has allowed us to query massive amount of AF Attributes to get their current values easily. Some AF attributes have been excluded in our system. For that case, we are not interested whether or not the values are bad. Hence I would like to know if I can filter out any AF Attributes that are ‘excluded’ in my query. The resulting query will give me current values of the attributes that are bad. Without knowing the tag names, it is impossible to rectify those bad inputs. We would need to open up AF again and trace the AF path to find out the tag names. It also limits our ability to deep dive on root cause using the same query. (eg. Multiple tags from the same interface are showing bad inputs – this is impossible without knowing the tag names).
  • Attach files
  • Kenneth Barber
    Aug 4, 2026

    This would give us 1 less reason to use PI OLEDB Provider. Currently, one advantage of the PI OLEDB Provider is that it does not rely on the PI Asset Framework (or, more accurately, it cannot use the PI Asset Framework) to return results that involve archived data. If a customer chooses to not use the PI Asset Framework, perhaps because they don't see enough value in using or maintaining it, then PI OLEDB Provider is, unfortunately, their best way to query PI Data Archive data programmatically.

    However, PI OLEDB Provider has many problems, such as relying on the deprecated PI SDK, running queries slowly (or at least more slowly than PI SQL Client), taking up more space than PI SQL Client, and it is too easy to write a slow query for PI OLEDB Provider (usually too slow to finish in any reasonable amount of time).

    Reply
  • GaryYegiazaryan
    Oct 19, 2022

    Just echoing what was said before in regard to being able to view the config string associated with an AF element attribute. This functionality already existed with OLEDB Enterprise.

    Reply
  • Guest
    Aug 23, 2022
    Muy útil y necesario en nuestras implementaciones.
    Reply
  • emetzler
    Aug 23, 2022
    We're having PI performance issues that are stemming back to slow PI OLEDB queries. Our tests show that PI SQL Client is much faster than PI OLEDB, so we want to replace OLEDB with PI SQL Client. Unfortunately, these queries are tied to PI tags and not AF. PI SQL Client connections to the Data Archive would resolve this.
    Reply
  • Guest
    Aug 23, 2022
    Would be great to be able to query the ConfigString of an AF Element Attribute, similar to what PI OLEDB Enterprise had. This would allow for example to see the source PI Tag for an Attribute, but also understand its Source Units of measure, as opposed to only having access to the Default UOM by querying the Attribute's UnitOfMeasure.
    Reply