3 of 3 people found this helpful
How about setting up an AFTable to be linked against a SQL table, which then could be kept in sync with the module database using PI OLEDB Classic?
Then you'd have a solution which could be configured instead of developed/compiled.
Open PI SQL Commander (or PI OLEDB Tester) and query pimodule to see what you get.
Thanx Asle. Good alternative. I looked at what it would take to populate a SQL table with columns for: ServerName, Interface Name, Executable, Point Source, UFO_ID, ... and..
I'm thinking it looks like a big Cross, for each item is in a different attribute record. I don't see the ability to create a Transform Value Function(TVF) to help flatten the query. The current project is in a dynamic state yet where the interfaces maybe migrating to different servers. Wouldn't maintenance of the SQL table be a night mare to pass on to the admin staff?
Use of a DataReference would be semi-self documenting with the AF-Attribute configuration string pointing the path to the interface attribute in question. The Attribute configuration string would be driven by the element template with substitution strings from the hierarchical model.
Has anybody else written an AF-Datareference for the MDB?
Any more Pros/Cons to the different approach?
Yeah, you're maybe right about the upkeeping / maintenance of it.
Back in 2005 we in Amitec wrote our own MDBSync project, so that we could use the MDB hierarchy supported through SQL Server in treeview components in front end solutions (the MDB itself was very slow). Some years ago we got the MDB-to-AF link (which unfortunately doesn't support the %OSI hierarchy), but the customer for our MDBSync project is still using it. It's simply a matter of using the PI SDK to access the PISDK.Servers.DefaultServer.PIModuleDB. With a little effort you should be able to create a small sync service.
But then again, if you're going to develop something, you might as well develop a custom DR specifically for the task. Just keep in mind that this executes on the client, so loading time is vital. You should really test the speed of doing the operations you need to do, before writing the whole DR framework.
I would just run a process on a server that uses the PowerShell Tools for the PI System that creates an AF Hierarchy with the associated information from the MDB (much like Asle described). Typically that is what I would do anyway for defining a monitoring solution for the interfaces, including information about buffering; performance counters, versions, etc.