Thank you.
This means that what I have suspected (double-invocation of the server) is *not* causing the problem.

At this point there are hardly any options left. About the last thing we can try is the OPC Analyzer. I do not have much hope, though.

Can you please try to collect OPC Analyzer traces from the "good" and "bad" scenario (and observe whether the use of the analyzer does not change the behavior).
Instructions are here: kb.opclabs.com/How_to_use_OPC_Analyzer .

I will send you a download link by email.

Best regards

Hello,
I have received the exported registry files by email, thank you (note the info they contain could be made public, there is nothing confidential in it).

From it, i can see that the OPC server is registered as "Local server" (as opposed to "Local service"). With servers registered in this way, (D)COM sometimes starts multiple instances of the server, which then causes various issues such as that the 2nd invocation does not work well. I want to rule out that multiple instances are being started (or to confirm it...).

Can you please:

1. Start Windows Task Manager.
2. Switch to the Details view, and sort the tasks by Name.
3. Verify that you are seeing processes for all users (not just you) - there should be "User name" column, and there should be users other you (e.g. SYSTEM, LOCAL SERVICE) with some processes.
4. How many processes named DVSYS.exe do you see at this point? Zero, one, or more?
5. Perform the "failing" test from your ASP script.
6. While running the test, observe the Task manager closely. What happens with regard to the DVSYS.exe processes? Is there any change, even temporary? Isn't there a moment in which two such processes run at the same time?

Thank you

Hello.
Thank you for the tests and explanations, it helps to understand your system and narrow down the possibilities.

I have some idea what can be causing this, for it I need to inspect how the OPC server is registered. Can you please provide me with .REG exported files according to the following article: kb.opclabs.com/How_to_obtain_OPC_Classic_server_registration_information ?

This would be for ProgId "DeltaV.DVSYSsvr.1" .

Many thanks

Thank you for your answers.

Re "What is unique about "results = Client.ReadMultipleItems(arguments)" such that "results(0).Vtq.ToString()" appears to return different results whether run from IIS or not?" That is a good question. it is the question I am trying to find the answer to. Currently I do not know the answer.

Re "From OPC client perspective, does the context of the string value matter?" Normally it does not. But in theory it can, if the server decided to deliver different results based on who is calling it. That is why I was asking.

Is the "ADMIN" user of the AppPool the same as the interactive user that is logged in when you made the tests from the console? If not, can you test setting the AppPool identity to that interactive user?

Also, the IIS should be set not to impersonate the Web app user - but I suppose you are aware of that, and that is what you meant when you wrote about preventing "client-side browser effect".

Regards

Hello.
Thank you for the information.

It appears that the results do not depend on the code or settings in the code. They depend on whether the code is run from the console app, or inside IIS.

Which leads me to following questions:

1. What is the actual semantics of the "THISUSER/USERNAME.A_CV" tag? Isn't it somehow supposed to tell who is using the server?
2. What is the user account under which the IIS AppPool runs your ASP script?
3. Are the different results (between console app or other apps, and your ASP script) limited to just selected tags, or are they across *all* tags in the server? If they limited to some tags, what are they - is there some pattern in it?

Thank you