dpQuery of _alert_handle attributes?

[MattPaulissen]

Is there a way to use wildcards do get the alert ranges with a query?

I would think this should work: SELECT '_alert_hdl.*._u_limit' FROM 'Level1.'

The alarm ranges are listed from 1 to n in between _alert_hdl. and ._u_limit. I'd like to grab them all in one go, but it doesn't seem to return anything with the wildcard. Is there a way to do this without having to use a dpGet on all the ranges?

[leoknipp]

It is not possible to use wildcards in the SELECT statement for a dpQuery().
You can use several attributes in the SELECT statement even if they are not used for the dp elements defined in the FROM statement, e.g. _alert_hdl.1._l_limit, _alert_hdl.2._l_limit
An error does not occur if the given attributes do not return a value.

Best Regards
Leopold Knipp
Senior Support Specialist

[MattPaulissen]

Can you think of a way to do what I'm doing more efficiently then?

I'm creating gauges that inherit their coloring from the alarm ranges setup in the tag. Currently I use a dpGet to get the number of ranges then I loop through all of them getting the _u_limit, _l_limit, and alarm class(in order to get the color from the alarm class.)

I feel like this is pretty inefficient since dpGets are rather inefficient. I would rather query them, with a dpQuery or dpQueryConnect, but it looks like that isn't possible.

[Gertjan van Schijndel]

I do not know a more efficient way as the query as described by Leo.

I would include the '_num_ranges' attribute to get the number of configured ranges, so you can discard the values (empty anytypes) easily from the other ranges.

[fmulder]

I can imagine that getting these limits, especially when you display multiple gauges, may cost time and that you'r screen will eventually look slow.

I can't imagine that these limits change all the time. That is why I would suggest two options:

1) Collect data like this wen you start the GUI and then remember this stuff in a global mapping
2) Collect this data when you're gauge shows. Let the gauge remembers its settings in a global mapping

The second option is basically what a dpGetCache(). It does one real dpGet() to get the value and stores it in a mapping. The next time you open the panel, the dpGetCache() will get the value from the global mapping and will be much faster.

You may consider your panel to be rich because it collects the limits automatically. However, this 'richness' may eventually lead to a slow GUI.

My general rule is : do not collect data each time you open the panel, when the data doesn't change (much).

share the fun
Frenk Mulder

[leoknipp]

Depending on the number of gauges displayed in the panel I do not see a problem when using some dpGet() commands to get the ranges and colors defined at the alert classes.
If there are only a few gauges (up to 20 - 50) displayed in a panel you can use a dpGet().
In a normal system processing 100 dpGet()-messages when opening a panel is not a big deal and every system should be capable to handle such an amount of messages in a short amount of time.

If you want to get the information for only one dp element you should use a dpGet() instead of a dpQuery(). A dpQuery is more complex and is normally used when reading the information for a pattern of dp elements (using wildcards) or a list of dp elements in one step.

Using dpGetCache() only works if you are also using dpSetCache(), otherwise you will get some wrong results and finding the cause is very tricky.
These functions shall only be used in very rare situations.

Best Regards
Leopold Knipp
Senior Support Specialist