Most of the sample code in the following topics do not include error checking and reporting:
Note: These examples exclude error checking to keep them as simple as possible. However, both common sense and accepted programming practices mandate that you include error checking in your ODBC code.
Give consideration to implementing most of the complexity of queries in Access Query Definitions where they are easier to design and the results are easily viewed. A WHERE clause can be used when calling the query to select only the desired rows at run time. Where tables have many columns (fields), the Access Query Definitions can be used to restrict any particular call to view only the fields of interest.
It is helpful to build the SQL test up into strings. Firstly the ODBC function calls become simpler. Secondly the strings can be passed to TraceMsg() to make debugging simpler.
Remember that the Jet Engine runs on the same PC as CitectSCADA and that complex queries returning large Recordsets can have an adverse impact on CPU and memory resources. However, excessive impact on PC resources can be avoided by careful table, query and relationship design.
If there is a need to execute the queries on a Remote Computer, the code can set up on a Reports Server or an Event Server. This is especially relevant if the code is to be triggered by an event in a PLC. If the code is to be triggered by a User at a Display Station, and the query is considered too CPU intensive, the Display Station can be used to set the PLC bit that calls to code or call the Report using the Cicode Report() function. Another possibility is to use the Cicode MsgRPC() function to call a Cicode function (with parameters, if necessary) on a remote computer. Each of these alternatives require CitectSCADA to be running on the remote computer.
See Also