AVEVA™ PI System™ Feedback Portal

Welcome to our new 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 Server
Categories Asset Framework (AF)
Created by Guest
Created on Aug 19, 2022

RELATED IDEAS

AF should react better to unhandled exceptions from a linked table provider

When an OLE DB or ODBC provider returns an unhandled exception for a linked table to the PI AF Application Service , it would be better for it either handle the exception and not crash, or to log the exception, the linked table name and provider name to the AF logs and stop gracefully.
  • Attach files
  • Guest
    Reply
    |     Aug 19, 2022
    One way of preventing the crash that was suggested is to have one or many sub-processes managed by the AFService.exe and dedicated for the linked table feature. This way if a memory exception is thrown, the sub-process could be stopped and not the AFService.exe and therefore avoiding an AF outage. There are some drawbacks to this idea. For example, adding a sub-process adds another layer the data must go through before being returned to clients which has some performance implications. If the sub-process where to crash, but AF was still running the linked table data could be outdated or an error could be returned causing considerable confusion for users. Asset Analytic outputs could be incorrect as analyses would still running. Etc... From OSIsoft's perspective, its more logical to fix the issue upstream, meaning using providers that handle their exceptions properly and don't run into memory / heap corruption issues as these are the most common causes for an AF Server to crash. Handling the symptoms downstream would be ideal, but there isn't a great solution for OSIsoft to implement. The best may be to simply stop the service gracefully with a meaningful error message.