# Extend named query with a query **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [March 27, 2025, 3:14pm UTC](https://forum.inductiveautomation.com/t/extend-named-query-with-a-query/104312 "2025-03-27T15:14:54Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 27, 2025, 3:40pm UTC](https://forum.inductiveautomation.com/t/extend-named-query-with-a-query/104312/4 "2025-03-27T15:40:50Z")
> [@Alejandro\_Alaco](#): > > they were extending the query somehow Was it a NamedQuery? If so can you show the actual named query? Technically, you can use a QueryString parameter to provide query text, but that is a security hole and IMO should be avoided when other tools offer a reasonable alternative. Take a look at this for more information: > [@runNamedQuery vs runPrepQuery](https://forum.inductiveautomation.com/t/runnamedquery-vs-runprepquery/81268/6): > > The original purpose of Named Queries was to make it possible to pass values into Vision Query bindings in a secure and efficient way, solving the unreliability of parameter stringification (looking at you, java.util.Date), and allowing the huge "legacy DB access" security hole to be closed. The maintenance advantages of NQs can be matched by multi-line strings for SQL in library scripts, so I tend to discount that item. However, not all is well. Some things to consider: NQs permit the use… --- _[View the full topic](https://forum.inductiveautomation.com/t/extend-named-query-with-a-query/104312)._