3 Replies Latest reply on Sep 11, 2014 1:30 PM by Gregor

    SQC Charts and Table Lookup Data


      I have a business case where I have data values in an oracle database that I wish to display in an SQC chart or trend chart or XY chart. I want to avoid having to duplicate the values in PI(not writing and storing into PI tags). Can anyone think of how this could be accomplished without duplicating in a PI Tag? I was thinking I could have a linked table lookup query that retrieves the last 20 records(samples). Is it possible to utilize these records in this lookup table for SQC or trending or XY without writing t a PI tag. We wish to avoid data duplication so we maintain "one version of the truth" Thank you so much for your thoughts and considerations.

        • Re: SQC Charts and Table Lookup Data

          Hi Mike,


          Off the top of my head I would look at using either a linked table in AF or using a the OLEDB COM Connector. Using the AF lookup approach should work with the SQC charts; I've used AF attributes in a number of SQC charts. AF linked tables do support time based look up; I can't remember exactly which version but it was fairly recent.

            • Re: SQC Charts and Table Lookup Data

              Hello Mike,


              I concur with Michael as far as AF table lookup is concerned. I've once tested this approach with time series data in a relational database table and it worked. Please be aware that we recommend limiting the amount of rows - I recall the suggested maximum was at 10 k with the AF version introducing table lookup functionality. I believe to remember that AF developers found a way to improve performance and that as a result the suggested maximum of rows was increased.


              When working in OSIsoft Technical Support I was dealing with some cases related to issues with PI Com Connectors. With PI Com Connectors a PI tag needs to be created as a kind of placeholder but there's no data stored in PI Archives. User queries against Com Connector tags become re-routed to the configured "foreign" system (e.g. a relational database with PI OLEDB Com Connector). The concept is simple and great but there exist issues e.g. caused by communication issues between the PI Com Connector and the "foreign" data source.


              AF Table Lookup would be my preference upon PI OLEDB Com Connector.