2 Replies Latest reply on Nov 22, 2011 4:08 PM by spilon

    ACE and SQL Server


      Hi There,


      Would it be possible to write ACE Calculation using SQL Server and later schedule them using ACE Scheduler? In other words we don't want to use Module Database for context information. I never used ACE with external RDBMS and wondering if somebody can provide me some insight.


      Thanks in advance.



        • Re: ACE and SQL Server
          Ahmad Fattahi

          As long as you can do something in .NET environment, you can do it in PI ACE. So you can think of it as your ordinary .NET environment loaded with extra PI SDK "hooks" and scheduling features.


          The metadata corresponding to your PI ACE calculation is stored in PI MDB though. That's how the product is built and I don't know of any way around it.

            • Re: ACE and SQL Server

              Do you want to store "accompanying data" (i.e. settings) for your PI ACE modules to run with, or you really want to store the context information in there and have the PI ACE Scheduler be based on that rather than the PI ModuleDB?


              If it's the latter, then the answer is no, this is not possible. PI ACE Scheduler relies on these settings stored in PI Module Database, which are now available through the PI Asset Framework if you use PI Server 2010 or later.


              If you want to do the first use case (store additional information to go with your modules), then Ahmad's answer is right: you can definitely query a relational database such as Microsoft SQL Server, from the PI ACE development environment. You can use the ActiveX Data Objects (ADO) objects in VB6 or the ADO.NET objects in the .NET environment. I would recommend you look into the "PI Application Development" training course (the class materials are available under the vCampus Training Center) - in that class we teach how to access our PI OLEDB Providers through ADO/ADO.NET... the same concepts apply to SQL Server (although you would use the SQL Server OLEDB Provider, not the PI OLEDB Provider).