In the nicest way possible, PI API is not recommended anymore, in favor of PI SDK. As a matter of fact, the OSIsoft vCampus program does not provide any development rights on PI API, neither does it support it (e.g. no documentation, no discussion forum). You should note that PI API is much older than PI SDK and therefore does not implement the latest connection/security mechanisms. Also, it is sequential as opposed to object-oriented and provides a much narrower breadth of functionality (variety of databases/objects you can access, what you can do with those objects, etc.).
These are just some of the reasons why OSIsoft does not recommend nor support it anymore... but beyond that, it is really just a matter of promoting the best products/technologies for your needs, and supporting the best practices. Please let us know what you are trying to accomplish and I'm sure the community and the vCampus team will come up with the best approach
Also, could you please elaborate on the "do not need the network layer stuff in the SDK"? I would like to understand what exactly brought you to the conclusion of using PI API instead of PI SDK - and hopefully help clarify a few things and point you to the right technology.
Thanks for the reply Steve,
I am writing a utility that runs as a service on the PI server, it does not need security but it does need speed. The requirements are high speed access. I am writing the utility in C so do not object orientation. Usually remote API's are slower even when run locally. This is why I chose to use the PI-API. If my assumptions are incorrect then please advise. The utility reads actual historical data from the archives.
How would I go about connecting locally using the PI-SDK and what kind of perfomance will I get compared to the older unsupported API ?
Connecting to a PI Server that resides on the local machine is exactly the same as connecting to one that's on a remote one. All you need to establish a PI SDK connection is that A) the PI SDK be installed locally and B) the name of the desired PI Server be in the Known Servers List - and these 2 requirements are already taken care of, on a machine that has the PI Server installed.
The code you would use is the one below, where "yourPIServer" is the name of the PI Server machine:
ServerPtr pServer = pPISDK->Servers->GetItem("yourPIServer");
The Open("") method - without the "UID=...;PWD=...;" connection string - should work because PI Servers typically have a couple of PI Trusts in place, such that local connections are accepted as PIAdmin with no need for a password.
Then as far as performance, I don't have actual benchmark results to share, but I would not be worried that the PI SDK will meet your needs... this actually is the technology we are using for all of own our client products. Please share any future observations you make on this technology (in the PI SDK forum) and I'm sure the rest of the community, including the PI SDK developers themselves, will be happy to help streamline and improve the way you use it.
Hope this helps!