Query Tag - FixedRate or Event Driven

Ignition
1

Hi,

I am writing energy consumption values to SQL tables using SQL Bridge, and I calculate the hourly consumption in SQL.

In Ignition Perspective, I then use Query Tags in an event-driven mode, where the tags are updated once per hour when new data is written to the SQL table.

My question is:
Is this a correct and recommended approach?

Would using an event-driven strategy be more efficient than a fixed-rate execution in terms of CPU and memory usage, especially considering that there are many such tags in the system?

I would appreciate your feedback and best-practice recommendations.

Thank you.

2

I wouldn't use query tags at all. Just use named queries in your UI where you want to display this information.

3

Thank you for the suggestion.

In our case, we have more than 50 energy areas, all stored in the same SQL table, and they are displayed simultaneously on a main dashboard using a Tab Container.

The hourly consumption values are already pre-calculated in SQL, and the data only changes once per hour.

I initially chose an event-driven Query Tag + UDT approach mainly as a caching mechanism at the gateway level, to avoid running the same named queries multiple times when several tabs are visible at the same time.

From a scalability and best-practice perspective, would you still recommend switching to named queries in Perspective bindings, or would a gateway-level cached approach be acceptable in this scenario?

4

Yes, because named queries have a caching mechanism themselves. Just set it up.

5

Thank you, I will edit this. I will do this using a named query.

6

The key to effective caching is to ensure you provide exactly the same parameters to the NQ. Since you probably need to use a timestamp parameter to get a specific period, make sure you truncate the minutes/seconds/milliseconds (set to zero) for the timestamp you provide to the NQ.

1 Like
7

Thank you for the clarification and the warning.

In our case, the datetime column is part of the primary key and uses smalldatetime, so the values are already normalized (no seconds or milliseconds). Each record represents a single fixed time period, so the timestamp parameter passed to the Named Query will always be identical for the same hour.

I appreciate you pointing this out, thougt it’s a good reminder to be careful with timestamp parameters when relying on query caching.

1 Like
8

Beware! While this may be true for the result on the SQL side, it is the actual java.util.Date passed to the NQ that will drive caching. Make sure you normalize before it is passed to the NQ.