Determining which values are being read or subscribed can be difficult or impossible. Documentation provides some answers, but is not exhaustive and a user could easily create configuration mistakes with un-intended consequences. Having a way to verify the final read/subscribe status of an OPC Item would improve transparency and reliability for the end user.

I've uncovered at least 2 bugs (possibly related) where the items are being subscribed when they should be read or visa-versa. Additional transparency will lead to bug fixes and greater reliability. Using Wireshark for detecting theses situations is time-consuming and may not always be practical.

Getting the read or subscribe property correctly set for an OPC item is critical to some SQL Data logging situations. This is particularly true where race conditions present a challenge. I've seen one or more posts where people discourage the use of the SQL-Bridge for logging batch data. My own testing confirms this conclusion. The read & subscribe issues have been the primary reliability problem for most batch logging issues I've encountered with transaction groups.