I do not want to propose another change; I just wanted to explain some things. Your original posts basically had 2 parts to it: 1) how to easily correlate the arguments to SubscribeMultipleItems method with the incoming event notifications - I think this part has been answered by now, and 2) how to build database rows with per-tag data with OPC subscriptions. It is this second part of the question that I want to comment. Perhaps you have already found s solution that works for you, but it's always good to have all the information.

If what you need to achieve is something like creating a table where each row corresponds to certain time, and the columns have the data values for certain tags, then the OPC subscription model does not directly fit with that, and some work on the coder's part is always required. In fact, the periodic reading approach (that you had originally), which is not otherwise recommended, make building such table much easier. OPC subscriptions are usually a preferred method, however there are some issues with them in this case:

1. Per the spec, OPC-DA servers only send data subscription notification for data values that have changed. That is, if the data has been collected anew from the device, but it has not changed the value, *nothing* gets sent to the client - therefore the client does not receive the new timestamp. It can assume that the data has not changed, but the timestamp is lost. This commonly makes life hard difficult for trending and logging packages based on OPC-DA. Some servers "get around" this by always or optionally sending data that have not changed as well, but strictly speaking, that's against the OPC specs. Newer specs (OPC Unified Architecture) allow the client to tell the server what the notification "trigger" should be - and it can be just a timestamp change.

2. OPC server are not required to send data collected "together" in one common ("packed") notification to the clients. While the physical data change notification contains one or more data changes, there is no guarantee that they belong together, and there is no guarantee that those that belong together are transferred at once. The "packing" is for physical (efficiency) purpose, not logical (semantics).

3. The above two apply generally to OPC-DA, this last one to QuickOPC only: Even if multiple data changes arrive to us together, we "unpack" them and have one notification to your code per data change - therefore you do not get to see the "packing" anyway. Given that the issue 2 above exists, this behavior itself should not be a cause for any additional problem, but it should be listed here for completeness.

What can you do then, if you want to use subscriptions, and generate a tabular log? You will probably need to put in some logic that will find the related data changes in the incoming stream of notifications (and you are probably doing that already). The logic may be based e.g. on the timestamps of the data (make a separate row if they are equal or close enough). There are many possible approaches - but they all require some extra coding.

One such example even comes with the product: If you open the Examples solution for C# or VB.NET and in the Solution Explorer, locate the project Console -> LogToSqlEnhanced, you will see it there.

Best regards

I will start form the end, as there is an easy answer to your last question. You can get rid of the Select Case statement, and simplify the code, by directly passing the index into the _r array as the State argument.

That is, pass 0, 1, 2, ... 9 instead of "A", "B", "C", ... "J". Then, in the event handler, do something like (I have not run it through compiler, but the idea should be clear):


Best regards
(One more post will follow later)

Received both your posts... planning to provide an extensive answer tomorrow. Best regards.

Regarding MultipleItemsChanged : This has been dropped in newer versions altogether, because it has not brought the performance benefit for which it has been meant. Use ItemChanged instead.