# Query Tag - FixedRate or Event Driven **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [January 11, 2026, 2:01pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200 "2026-01-11T14:01:42Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Batuhan\_Parlakay](https://avatars.discourse-cdn.com/v4/letter/b/e47c2d/32.png) [@Batuhan\_Parlakay](https://forum.inductiveautomation.com/u/Batuhan_Parlakay)\ **Post date:** [January 11, 2026, 2:01pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/1 "2026-01-11T14:01:42Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 11, 2026, 3:02pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/2 "2026-01-11T15:02:39Z")
I wouldn't use query tags at all. Just use named queries in your UI where you want to display this information. ---
**Author:** ![Batuhan\_Parlakay](https://avatars.discourse-cdn.com/v4/letter/b/e47c2d/32.png) [@Batuhan\_Parlakay](https://forum.inductiveautomation.com/u/Batuhan_Parlakay)\ **Post date:** [January 11, 2026, 3:12pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/3 "2026-01-11T15:12:47Z")
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? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 11, 2026, 3:27pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/4 "2026-01-11T15:27:40Z")
Yes, because named queries have a caching mechanism themselves. Just set it up. ---
**Author:** ![Batuhan\_Parlakay](https://avatars.discourse-cdn.com/v4/letter/b/e47c2d/32.png) [@Batuhan\_Parlakay](https://forum.inductiveautomation.com/u/Batuhan_Parlakay)\ **Post date:** [January 11, 2026, 3:47pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/5 "2026-01-11T15:47:52Z")
Thank you, I will edit this. I will do this using a named query. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 11, 2026, 3:50pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/6 "2026-01-11T15:50:28Z")
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. ---
**Author:** ![Batuhan\_Parlakay](https://avatars.discourse-cdn.com/v4/letter/b/e47c2d/32.png) [@Batuhan\_Parlakay](https://forum.inductiveautomation.com/u/Batuhan_Parlakay)\ **Post date:** [January 11, 2026, 4:06pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/7 "2026-01-11T16:06:35Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 11, 2026, 5:00pm UTC](https://forum.inductiveautomation.com/t/query-tag-fixedrate-or-event-driven/113200/8 "2026-01-11T17:00:31Z")
> [@Batuhan\_Parlakay](#): > > are already normalized 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.