# runNameQuerry in IGNITION **URL:** \ **Category:** Ignition\ **Tags:** ignition79, scripting\ **Created:** [April 16, 2020, 3:32am UTC](https://forum.inductiveautomation.com/t/runnamequerry-in-ignition/33971 "2020-04-16T03:32:19Z")\ **Posts on this page:** 1\ **Showing post:** 5
**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:** [April 16, 2020, 11:07pm UTC](https://forum.inductiveautomation.com/t/runnamequerry-in-ignition/33971/5 "2020-04-16T23:07:11Z")
> [@WillMT10](#): > > We have a project where all the tags are driven by sql queries. No device connections. We try to reduce the number of queries with a handful of query tags, but then have a UDT defined that pulls in the necessary information from these root query tags based on the UDT instance name. Within each of these UDTs (dynamic number, but could be up to 2,000 UDT instances, maybe more in the future) we have a handful of tag event scripts for doing some of the heavier lifting that would be too difficult with expressions alone. The tag events write back calculated values into other memory tags in the same UDT. I would do all of this with a timer script that runs the repetitive SQL, fans out the raw data to the target UDTs (recipients would be memory tags, not expressions), and perform all of the "heavier lifting", also writing to target memory tags. Multiple driving SQL queries would each get their own timer event. This approach has minimum efficiency lost to multi-threading and minimum skew between data arrival and final results distribution. Timer events naturally prevent overrunning, so final target results are sure to be delivered before the next query is run (if anything bogs down the DB or GW). Be sure to optimize tag writes with lists of tags and values, and use .writeSynchronous/writeBlocking to keep each event deterministic. > [@WillMT10](#): > > We have a gateway script to check for new device deployments and when found, automatically adds a properly named UDT instance. I just don’t know how I would automatically update the tag change script to include these new instances. With the above design, there wouldn't be a tag change script. (Which is good, since there's no way outside the designer to update the list of subscribed tags.) I'd simply cache a list of UDT instances in the script module and reference it in the query event. Let your UDT-searching script populate/update that list for the query event(s) to use. In a pinch, if you really must, you can use the gateway's context to access the tag manager, and add and remove your own tag change listeners. There be dragons that way, though: > [@Some Project Resources not publishing](http://forum.inductiveautomation.com/t/some-project-resources-not-publishing/16888/3): > > This may be a side-effect of the fact that Ignition doesn’t/can’t track the usage and retention of python code objects throughout the gateway. This means that when your script modules have interlocking dependencies, updating one script won’t impact the code objects that other scripts have imported. You may need to make a trivial change in all of your scripts and save them all together to get it to “take”. You may also need to disable then re-enable the entire project. Consider renaming the o… --- _[View the full topic](https://forum.inductiveautomation.com/t/runnamequerry-in-ignition/33971)._