Hello,

please make sure you have read these:
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...tml#Connection%20handling.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...tion%20Control%20Services.html

Basically, I think that what happens under the hood is somewhat different from what you have assumed.

With default settings, unless the connection is "held" by a subscription, QuickOPC will disconnect after some time when it is not needed. If you code just the Read e.g. in context of serving a Web request, then the connection will be kept open when the Read-s are coming quickly enough in succession (less than 5 seconds or so in between). When there is a longer delay, QuickOPC disconnects. And it will then re-connect automatically when a new Read is requested.

The disconnections are normal. What is happening there is that probably some re-connections fail with BadUserAccessDenied. So, in my estimation, most likely, BadUserAccessDenied is not *causing* any disconnection. Instead, it is an error that the server gives upon some re-connections.

QuickOPC normally only uses one connection to any target server. It rare circumstances, usually with network disruptions, the server may see more than once connection from the client while the client thinks it only has one connection. This cannot be prevented.

The proper way of resolving this would be to figure why the server is giving BadUserAccessDenied, and fix it. Eveyrthing else are just workarounds.

If you wanted to cause "quicker" disconnection after a Read, you could set the EasyUAClientConfiguration.SessionParameters.AdaptableParameters.HoldPeriod to a low value. But, in my view, if you wanted to work around the issue, you actually need to *prevent* disconnections, by setting this property to a *high* value. Alternatively, the connection locking can be used (see the documentation), or roughly the same effect can be achieved by setting up an OPC UA subscription to any (even non-existent) node and keeping it subscribed.

Regards