First and most importantly, you should not try to write any reconnection code. There is no need for it, and it would almost for sure interfere with QuickOPC's own reconnection logic. As described in the "Best Practices" chapter in the the Concepts document:

13.1 Do not write any code for OPC failure recovery
As described in FAILURE RECOVERY, problems in communications with target OPC server are automatically recognized, and the component performs the recovery automatically. Attempts to duplicate this functionality in your code will interfere with this mechanism and won’t work.
It is fine (and indeed, suggested) to catch the errors and handle them appropriately. But the error handling should not include attempts to remedy the situation.

And the referred chapter:

12.12 Failure Recovery
The OPC communication may fail in various ways, or the OPC client may get disconnected from the OPC server. Here are some examples of such situations:
• With OPC Classic, the OPC server may not be registered on the target machine – permanently, or even temporarily, when a new version is being installed.
• With OPC UA, the OPC server may not be running or registered with the discovery service on the target machine – permanently, or even temporarily, when a new version is being installed.
• The (DCOM, TCP, Web service or other) communication to the remote computer breaks due to unplugged network cable.
• The remote computer running the OPC server is shut down, or restarted, e.g. for security update.
• The configuration of the OPC server is changed, and the OPC information (item in OPC Classic, node and attribute in OPC UA) referred to by the OPC clients no longer exists. Later, the configuration could be changed again and the OPC item may reappear.
• The OPC server indicates a serious failure to the OPC client.
• The OPC Classic server asks its clients to disconnect, e.g. for internal reconfiguration.
QuickOPC handles all these situations, and many others, gracefully. Your application receives an error indication, and the component internally enters a “wait” period, which may be different for different types of problems. The same operation is not reattempted during the wait period; this approach is necessary to prevent system overload under error conditions. After the wait period elapses, QuickOPC will retry the operation, if still needed at that time.
All this logic happens completely behind the scenes, without need to write a single line of code in your application. QuickOPC maintains information about the state it has created inside the OPC server, and re-creates this state when the OPC server is disconnected and then reconnected. In OPC Classic, objects like OPC groups and OPC items are restored to their original state after a failure. In OPC UA, objects like OPC subscriptions and OPC monitored items are restored to their original state after a failure.
Even if you are using the subscriptions to OPC items (in OPC Classic) or to monitored items (in OPC UA) or events, QuickOPC creates illusion of their perseverance. The subscriptions outlive any failures; you do not have to (and indeed, you should not) unsubscribe and then subscribe again in case of error. After you receive event notification which indicates a problem, simply stay subscribed, and the values will start coming in again at some future point.

Second: "Setting a pointer to NULL" may or may not be correct, it depends on the kind of pointer you are using, and whether you have other pointers to the same thing. Simply setting a regular pointer to NULL does nothing to EasyOPC, the component wouldn't even know about it. What is needed is that all references to it are released (using the IUnknown::Release() method), this is a general COM rule. How this is achieved - the component does not care. If, for example, you are using smart pointers and using them correctly, then yes, setting them all to NULL would be the right way of disposing the object.

Third: It is recommended that you explicitly unsubscribe, before disposing of the component. You can use EasyDAClient.UnsubscribeAllItems(), or EasyAEClient.UnsubscribeAllEvents().

Best regards

Yes, if you are using the COM interface, just go for the latest version, i.e. 5.31 currently.

I will send you the temporary license to the email address that you have registered with this site. It can be placed on multiple computers.

Best regards

The operating system, and the fact it is 64-bits, should not be a factor here.

We have had similar issue, but not directly related or "triggerable" by connectivity losses.

The trial gives valid data for 30 minutes since the process (EASYOPCL.EXE in your case I believe) starts; after that, it gives an error instead. We can give you say 30 day evaluation license that has no limitation other than the absolute end date, - let me know if you need it then.

Best regards

This may be a problem inside QuickOPC. However, we do not support version 5.11 any longer.

My suggestion is that you rebuild your application with the latest version, and re-test. If it resolves the problem, I will get you an extra good deal on the version upgrade, not the usual 50% of the new license price. If switching to the newest version does not resolve the problem, we will be in better position to troubleshoot further (although not an easy position either, unless we can reproduce it here).

Best regards