This article has been inspired by an e-mail conversation we have recently had with a customer. He had written a piece of code "from the scratch" that connected to his OPC Data Access server, and was able to obtain the data he needed to store in a database. He therefore had doubts about the value and usefulness of a library such as QuickOPC; it appeared to him that the task of writing an OPC client is quite easy.

During the course of a discussion, we have identified quite a lot of points that his code was lacking. Here are some questions we have asked:

• Do you have a code that handles the situation when the OPC server is stopped, or simply crashes?
• What will happen if the OPC server does not report an error, but simply blocks and stops returning any values?
• Do you have a code that calls GetServerState, checks whether the server is not in a "failed" state - and if so, what then?
• Are you aware the the OPC server may ask its clients to disconnect (using the IOPCShutdown interface), or are you going to simply ignore this?
• Do you have a code that in all above (and other) situations will gracefully disconnect, and attempt to reconnect after some time later?
• If you need to reconnect, how do you restore the connection back to the state it had before? Do you keep track of OPC groups and OPC items that need to be added to the OPC server again?
• What if storing the data into the database (inside your subscription callback handler) takes more time than usual? Are you aware that you must not block the OPC server inside the callback handler in any case?

It turns out the the above mentioned issues are just a fraction of what an OPC client must do properly in order to be OPC compliant, and at the same time robust and reliable. When you use QuickOPC, all of it is taken care of automatically. For example, when an error occurs that causes a disconnection from the server, you will receive an ItemChanged event notification, and after a configurable delay, QuickOPC will reconnect again and will restore the original state of the connection (OPC groups and OPC items inside the server). There is no way you can develop a code for all of this in several days, let alone to be prepared for idiosyncracies of some non-compliant OPC servers, and unexpected traps and pitfalls of the OPC specifications. The OPC client code in QuickOPC is a result of more than ten years of development, and extensive testing and resolving all possible, common and rare, situations.

But of course, decision between "develop your own" vs. "use a proven toolkit" is in your hands...