When a point is deleted on the server and a PI-SDK application already holds a PIPoint object for that point, calls to the server through that point will return the error psePIPOINTDELETED. When this error is received, it indicates that the PIPoint object is no longer valid. The application should release its reference to the PIPoint object. If an application, when receiving this error, suspects that a point was deleted and a new tag of the same name was added (perhaps to change the pointtype), the application can retrieve the PIPoint again from the Servers PIPoints collection. This retrieval will either succeed, returning the new point of that name, or fail if there is no such point on the server.
When a call is made to Server.Open, after establishing a connection, the PI-SDK retrieves the ServerID from the server and compares it to a value stored in the Known Servers Table on the local machine. When the locally stored value does not match that returned by the server the open call returns pseSERVERIDMISMATCH. This return is intended as a warning however COM calls only support error returns. Because the return is informational, the connection is left open and if ignored the application proceeds normally.
The purpose of this behavior is to detect when an existing PI server has been removed and a new PI server installed in its place. At the lowest level, the PI-SDK connects to a machine name or IP address as configured in the Known Servers Table. If the system at the configured address responds to PINet protocol as if it were a PI server then it can appear to the user as the same PI server they used before the move. If similar tag names exist, the user may base decisions on irrelevant information. Note on a server upgrade, the ServerID remains the same so the mismatch error is not raised.
Detection of the mismatch condition relies on the PI-SDK persisting the ServerID. When a server is added to the Known Servers Table there is an option to specify the ServerID. Typically this option is not used and instead the PI-SDK notes it will need to retrieve and store the ServerID on the first successful connection. In either case, once the ID has been stored in the registry, if a PI server at the configured network path responds with a different ServerID during the Open call, the error will be raised.
There are several ways to resolve a mismatch but the key is to determine what has actually happened which requires user interaction. An application, when detecting this condition, can explain the issue in a dialog and allow the user to select a different server, modify the locally stored ServerID, or add the ServerID to the Servers.Aliases collection as an acceptable alternative ServerID.
In particular the secondary interface, IServerID, supports two methods that can be employed to this end. IDFromServer exposes the ServerID that the server is returning. This can then be added to the Servers.Aliases table or used to recreate the server entry in the Known Servers Table through Servers.Remove and Servers.Add. The ResetKSTServerID method, when called, resets the Known Servers Table entry for the server to the initial state before the ServerID was retrieved. After calling this method, the next time the client connects to that server, the ServerID will be retrieved and stored.