I think there are 3 things to discuss here:
1. How to recognize that a server is unavailable (or available again).
This isn't fully in aligned with QuickOPC model, because what we are trying to do is to hide the existence of connections to the server, and expose only the OPC items as the entity you work with, and has status. For example, if the connection to the server is broken, we generate an error, and multiplicate it and send notifications for each and every item affected - but there is nothing for the server itself.
There are several options here. For start, can't you subscribe to some kind of status item in the server (some that resides directly in the server and does not need a communication to any downstream devices), and interpret it as an indication of the connection status? If you receive an ItemChanged notification for this item with .Exception != null, it would mean the server is unavailable, and vice versa.
2. What to do when it happens (a server becomes unavailable, or available again).
First, although I know it's probably not the solution, remember that in theory you can stay subscribed to both the primary and secondary server all the time, and just take the valid data and throw away the errors from the unavailable server. QuickOPC will take care of re-connecting to the failed server after a configurable period, be it the primary or secondary one.
If the above is not an option, and you want to truly switch the servers, then you will need to unsubscribe from all items referring to the current server, and subscribe again to the same items, but in a new server.
3. How to do it.
This is just an implementation exercise - making sure you, as you pointed out, that you subscribe again with proper machine name in the arguments. Nice thing here is, if you use the State parameter/property to identify the items with something of a meaning of your app (and then interpret the State in the event handler), the State can stay the same between the primary/secondary server subscriptions, and the event handler for the ItemChanged events will stay without a coding change - the incoming events will look the same (have the same State value), no matter where the item comes from.
I hope this helps. Please be patient with our replies in coming two weeks - see the notice above the forums.
Best regards
