15 Replies Latest reply on Jun 14, 2010 12:43 PM by Harry

    Connection to Collective problem. Error: -2147220310


      I get the error, "The server is already open under a different connection string.  Close the server before attempting to reopen it.  Sever causing the problem: MVPIOne.


      Call Stack:
      General: ConnectServer


      The problem occurs when I attempt to search for a tag using the Tag Search utility.  This does not present a problem when connecting to a stand alone PI server.  The connection to the collective is handled with the following code:


        If (PISrvr.Connected) Then PISrvr.Close
        Set col = PISrvr
        If (col.IsCollectiveMember()) Then
          Set colList = col.ListMembers
          Set colMember = colList(PISrvr.Name)
          Set PISrvr = Nothing
          Set PISrvr = col.MemberOpen(colMember, "UID=" & Me.txtUser.Text & _
                    ";PWD=" & Me.txtPasswd.Text)
          PISrvr.Open "UID=" & Me.txtUser.Text & _
                    ";PWD=" & Me.txtPasswd.Text
        End If

      The TagSearch object is launched with the following code:


        Set nvsServers = New NamedValues
        nvsServers.Add srv.Name, 1
        Set ptList = TagSearch.Show(nvsServers, tsoptDisableServerPickList + tsoptSingleSelect)

      Note that I prevent the user from selecting a different server or selecting multiple tags.  This code immediately follows the connection to the server.  This is an Excel addin that I am trying to test on a PI Collective.




      Any suggestions?

        • Re: Connection to Collective problem. Error: -2147220310

          From the PI SDK Manual:

          This is intended for server management use. A Server object obtained this way does not support failover. When members of the collective are opened in this way, the collective itself cannot be opened. Likewise when the collective is opened normally, MemberOpen will fail. These are mutually exclusive connection mechanisms.


          As you collective is already open - MemberOpen fails. To switch between the servers, you may use something like (sorry for the c# snippet - had it just available from another call):

          g_piCollective.SwitchMember("", m_collectiveMember);
          m_piServer = g_piSDK.Servers[g_piCollective.CollectiveName.ToString()];

          where g_piCollective is the IPICollective, g_piSDK is the PISDK, m_collectiveMember is the CollectiveMember and m_piServer is the Server.



            • Re: Connection to Collective problem. Error: -2147220310

              Thanks for the reply Andreas.  I needed to connect to the collective which I accomplished by using:


                  Set PISrvr = PISDK.Servers(col.CollectiveName)


              As you suggested.


              Now that I can select a PI tag though, I need to be able to update history on all of the members of the collective.  This is presenting to be a bigger problem than I had thought.  I recall reading some where that when writing to history only the primary archive is updated.  So I expected to have to manually connect to the other member servers and update them.  So far I have tried


              * - connecting to the collective and switching the member alone (doesn't update secondary)
              * - switching the member and resetting the server to the secondary server (doesn't update secondary)
              * - switching the member and Opening the secondary member (causes errors)
              * - closing the connection to the collective and Opening the member (causes errors)


              Are there any suggestions on how this could be done?  Can the primary force a synchronization with secondary servers?  Or are archive updates just lost?



                • Re: Connection to Collective problem. Error: -2147220310



                  unfortunately it is some work on you side (unless you have time to wait for Server Side Buffering):

                  • you connect to the collective
                  • you write to the first member
                  • you switch to the second member
                  • you write to the second member
                  • you do the steps above for all members if there are more

                  In addition you have to "buffer" in you application if you can't write to a member. But that is something you need to do anyhow as long as there is no PI SDK buffering - regardless of writing to a collective or a single PI Server.


                  Hope this helps,

                    • Re: Connection to Collective problem. Error: -2147220310



                      I have tried doing this with no success.  As you know, to update the PI archive you have to have a PIData object which you get from a PIPoint object which you get from a Server object.  There is no way that I know of to get a PIPoint object from a CollectiveMember object.  Switching Members does not change the connected Server object.  It remains connected to the collective.  so it looks like you have to add a few more steps.  After switching to the next member of the collective, you have to close the connection to the collective and initiate a new Server object using MemberOpen as in:

                      For Each colMbr In col.ListMembers
                          col.SwitchMember , colMbr

                          Set srv = Nothing
                          Set srv = col.MemberOpen(colMbr, "UID=" & currUser & ";PWD=" & UsrsPwd)
                          If (Err.Number <> 0) Then Exit Sub

                          Set pipt = srv.PIPoints(arTokens(1))

                      This, at least, appears to open the second member of the collective.  I am now trying to figure out why I get the error "Writing, editing, or removing time series data on this collective member is disabled." when I try to write to the second member.


                      I've sent a request to techsupport to try to resolve this.

                        • Re: Connection to Collective problem. Error: -2147220310



                          I have gone through several documents now and read some discussions. On the bottom line the answer is you should not write to the collective from the PI SDK with the current version (1.3.x). There are ways arround your problem but the strong recommendation is wait for PI SDK 1.4. As mentioned above you would need to take care on buffering etc. by yourself and chances are good that you end up with inconsistent data on the primary and secondary server.


                          Here is what the Engineering Plan offers to solve your problem in the recommended way:


                          PI SDK 1.4.0 1Q-2010 Windows
                          Feature Description : PI SDK buffered data writes.  This also includes the capability to distribute data to all members of a PI server collective.


                          Hope this helps,

                  • Re: Connection to Collective problem. Error: -2147220310



                    This is Harry on the SDK team.  Andreas was correct that we highly recommend waiting for SDK buffering if you need to use the SDK to write data to members of a collective OR use the PI-API and have either bufserv or PIbufss running and configured to buffer and fan data to collective members.  That being said, the reason you are getting an error when trying to write data to the secondary is most likely because the secondary has the ability to write data from the PI-SDK disabled - which is the default.  That behavior is managed by a setting in the PI server's timeout table on each node.  The name-value pair Replication_enableSDKWriteValues is likely set to 0 on your secondary nodes.  PI-API connections are not affected by this restriction which is why PI-API writing and buffering works.  You would need to get your PI administrator to open up writing to the secondaries if you need this behavior.  As we expect to handle this automatically in the next release of the SDK we don't want to advise programmers to spend time writing complicated code to write to various members and have to devise their own algorithms for handling failures.  It is important to us that the data streams in a collective stay consistent.  We don't want your users to make decisions using inconsistent data. 

                      • Re: Connection to Collective problem. Error: -2147220310
                        I'm running into a similar issue and would like to voice my request for SDK buffering to come soon. :)
                          • Re: Connection to Collective problem. Error: -2147220310

                            It is under development.  We are not code complete yet so there will still be some delay.  Your patience is appreciated.  We want to get it right. There are many different states to handle and test. 

                              • Re: Connection to Collective problem. Error: -2147220310

                                Are there any other potential problems with turning on Replication_EnableSDKWriteValues besides the complexity of the code used to write data to the PI Server?

                                  • Re: Connection to Collective problem. Error: -2147220310

                                    Only issue I came across was if a collective member does not receive the data from the SDK application (it is down, priority of -1 etc), then the collective data starts to become out of sync.  Unless you create your own buffering and/or transaction (all members get it otherwise no members get it) type of mechanism then you just need to check the data on each member, which is not a trivial tasks but an extra overhead.

                                    • Re: Connection to Collective problem. Error: -2147220310

                                      Unless this is time critical for you, it is probably better to wait for SDK Buffering coming out later this year.  Then you just write and let the system worry about delivering it to all the members when they are available. 

                                        • Re: Connection to Collective problem. Error: -2147220310

                                          Harry, without SSB I presume the ability to buffer to unavailable members is reliant on the client machine staying online?  Let's say you have a client application, it sends some values to a collective where 1 member is unavailable.  Will the buffering of the 1 member continue after network disconnections/reboots/shutdowns etc of the client machine?

                                            • Re: Connection to Collective problem. Error: -2147220310

                                              Yes.  Once the data has made it to the buffers it will remain there and pibufss will continue to try to send it regardless of reboots.  If the machine is never turned on again then the data can be lost. 


                                              There is an additional caveat regarding security and newer servers.  The current plan supports impersonation of the sender (a feature not supported in earlier buffering solutions) so the data sent by the buffering system is sent under the original users credentials.  For 3.4.380 and above servers, with impersonation, if the originating application (such as an SDK interface) that has the proper credentials is never able to establish a connection to each member of a collective before shutting down, the data in the buffers for the unconnected buffers is orphaned.  The SDK connects to each collective member for the purpose of requesting credentials for pibufss to use on its behalf (a token exchange process).  If it can't do this over the lifetime of the application then pibufss has the data to send but no credentials to use. The individual collective members have limted knowledge of each other and don't exchange information about current connections or authentication beyond the security configuration. Pibufss will expose these buffers as orphaned and it will know what application sent them and the name of the logged on user when they were sent.  There will be utility software provided to alert a user to these orphaned buffers and provide credentials to send those buffers.  For most long running apps, like interfaces, we don't anticipate this occuring very often.  When server side buffering is released, presumably, the client will only need to authenticate to one member but the security token transfer on the server side is not yet designed to my knowledge.