[posted from an email conversation]
In a nutshell, we requires ready access to this data. Whilst you do provide web interfacing ? we would prefer to be able to access the data as, when and how we require.
Looking at the diagram below - there are two interfaces to consider. We may require one or both depending on what data can be stored.

SAP MII requires direct READ ONLY access to your DB using an ODBC connection. This ensures that we will not be able to change or modify any data. It also means that we will be able to query data as and when we require it and fits in with [our client's] current architecture very well. (We currently do this with the PowerSmart data at [another site])
We would also like the meter data to be stored on our historian ? preferably every x seconds (depending on capability). It has been suggested that we utilise an SNMP connection to the historian. [still another site] makes use of the GE Proficy Historian and after some investigation, I am told that Proficy does not come with a native SNMP interface. I need to verify this further ? but we may need to look at the possibility of using an OPC Interface?

In closing, the solution must ensure open access to the meter data. It does not make sense to isolate this data ? especially in the current climate of energy awareness. We currently interface with many other systems within our organisation in order to determine Power Costs per Ton of [product]. It is vital that the [new site] solution allows for this going forward.
I look forward to your feedback

Regarding direct SQL database access, if you have your own dedicated PNPSCADA server on site, we can open that specific server's PostgreSQL database to you, and you can access it through ODBC ( http://www.postgresql.org/ftp/odbc/versions/ ).
However, please be aware that this is not one of the interfaces into PNPSCADA that we officially support, and when you use the data in the database as is, we do not take any responsibility if you interpret the data incorrectly or inaccurately. Furthermore, some of the data e.g. real time data does not live in the SQL database. In the SQL database you would typically find historical and configuration data only. To access these, we prefer it if you use the comprehensive Restful Web Services that we support (http://www.pnpscada.com/webservices.jsp); and we guarantee that even if the PNPSCADA implementation may change as new versions of the software is released, the web service API will remain the same. We do not guarantee this with the underlying SQL database structure.
For real time data, we currently support three machine to machine interfaces (over and above the normal web interface we provide users); and these are SNMP, OPC Client, and Restful Web Services.
Regarding the SNMP, we have two industrial sites running with this, and it is by far the quickest to install and the easiest to support. At Mondi Merewent in Durban we're reading 54 meters every 20 seconds, and pushing the real time energy values into their SCADA system. They claim to save more than R100k per month on their Maximum Demand as a result. It is also used at Namibian Breweries, the home of Windhoek Lager.
Regarding the OPC Client, which is a technology essentially built on Microsoft Windows, we need you to already have an OPC Server elsewhere, since PNPSCADA is not an OPC server. PNPSCADA can push values into an OPC Server. Since we run on Linux, we need to do this over DCOM (remote ActiveX). Unfortunately OPC over DCOM - while possible - is in my opinion not viable on recent Microsoft Windows Platforms, due to excessive security requirements. The first thing to do, is to get it working between two Windows machines, and once this works, to then substitute the PNPSCADA OPC Client for the other windows machine, based on username password authentication. However, the first hurdle is just to get it working from Windows to Windows over DCOM, and this is a much more formidable requirement than what it seems at first! If you have a separate PLC device e.g. a MOXA OPC Server, this could be easier to interface to, and if you go the OPC route, we advise that you rather do that than to try and interface directly into a Windows box over the network.
The PNPSCADA OPC functionality makes use of the OpenScada Utgard Project functionality, about which you can read more here: http://openscada.org/projects/utgard/
Regarding accessing real time data over the Restful Web Services, the interface is simple: you browse a URL (http or https) with the meter number and login credentials included in the URL (or POSTed); and it returns an XML tree with the most recent real time values, with timestamps. You can call this as often as you like. We will read the meter as quickly as we can, up to keeping the meter up to 50% busy (so that other tasks or people can also access the meter if they do retries).
So, yes, we support all the avenues that you have listed, although I personally am of the opinion that some of the choices listed may not necessarily be the easiest solution or have the best results long term. I just want to make clear that these potential problems that I see, namely a change in the underlying SQL DB structure of an application as it is upgraded, and Windows Security limitations on remote ActiveX operations, are inherent in the technologies, and not in PNPSCADA, so the advice I gave also applies generally, not only to PNPSCADA. It is generally a bad idea to do direct SQL access, and it is generally difficult to use OPC remotely.