This is truly not related to the issue, so please start a new forum thread.

Hello,
thank you for your effort and the answers.

Unfortunately, this gave no further clues. I cannot think of anything else to try. In my view this is most likely a problem in the OPC server, which other OPC clients would get too *if they ran from inside IIS*, but I cannot prove it.

I am sorry but I cannot help further here.

Best regards

Hello.

As perhaps a last attempt, please try the following three experiments (without OPC Analyzer). Always just one of them, do not combine them. And, make sure the IIS (or at least the App Pool's working process) is restarted between the tests.

1. Place this code at the very beginning of your ASP script, before any QuickOPC operation:

 

Dim ComManagement: Set ComManagement = CreateObject("OpcLabs.BaseLib.Runtime.InteropServices.ComManagement")

ComManagement.Configuration.InstantiationParameters.OverrideDefaultSecurity = False

 

2. Place this code at the very beginning of your ASP script, before any QuickOPC operation:

 

Dim ComManagement: Set ComManagement = CreateObject("OpcLabs.BaseLib.Runtime.InteropServices.ComManagement")

ComManagement.Configuration.InstantiationParameters.TurnOffActivationSecurity = True

 

Dim ClientManagement: Set ClientManagement = CreateObject("OpcLabs.EasyOpc.DataAccess.EasyDAClientManagement")

ClientManagement.SharedParameters.ClientParameters.ComInstantiationParameters.TurnOffActivationSecurity = True

 

3. Change your EasyDAClient object instantiation to look like this (with possibly different variable name for 'Client', that's up to you):

 

Dim Client: Set Client = CreateObject("OpcLabs.EasyOpc.DataAccess.EasyDAClient")

Client.InstanceParameters.EnableNativeClient = False

 

Thank you

Hello.

Because the symptoms have changed with the Analyzer, we cannot directly conclude anything. In addition, the trace from the "Bad" scenario is empty - it does not contain any requests/responses.

However, in my experience, this again points to the same suspicion: A new, different instance of the target server is being started, when the client is in ASP/IIS.It is clear that some OPC communication has been taking place in the "Bad" scenario with the Analyzer. Yet the analyzer trace you saved is empty. Since the error returned was "The item definition doesn't conform to the server's syntax", it looks like that ASP/IIS was again communication with a different, hidden instance of OPC Analyzer - and this one was not (could not be) configured with any target server, and that's why it is returning an error.

Every time I saw this before, it was before the COM/DCOM somehow perceived that the client in IIS/ASP needs a new instance of the server - and it was because of security (user account).

(I do not have an explanation as to why you have not actually observed the second instance, but it might be an issue on your side, sorry).

I will follow up with a post where I will suggest to experiment with some more QuickOPC settings. But this would really more of a last desperate attempt, without firm base in reasoning.

Regards

Thank you.

It appears that the OPC server only supports OPC DA 1.0. But the OPC Analyzer only supports OPC DA 2.0 and 3.0. So, we cannot it.
With this, my options are exhausted. I still believe this is a problem in the OPC server (and with the analyzer we might have been able to decide this, or find a workaround).

Regards

Hello.

If you use REGEDIT and select the "HKEY_CLASSES_ROOT\DeltaV.DVSYSsvr" key (not HKEY_CLASSES_ROOT\DeltaV.DVSYSsvr.1" !), does it have "OPC" key, similarly to the picture below?



Thank you