# Can a NamedQuery be embedded in another NamedQuery? **URL:** \ **Category:** Ignition\ **Tags:** namedqueries\ **Created:** [August 3, 2023, 2:46pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371 "2023-08-03T14:46:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![stan.cook](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/stan.cook/32/10553_2.png) [@stan.cook](https://forum.inductiveautomation.com/u/stan.cook)\ **Post date:** [August 3, 2023, 2:46pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/1 "2023-08-03T14:46:19Z")
I have a named query "P" which produces a list of people. I want another query "W" which will produce a list of tasks that are owned by anyone in the list produced by query P. The P query is complicated enough that I do not want to replicate it within W, I just want to reference P like it was a database table (e.g. "select task from tasktable where owner in P"). Is this possible? ---
**Author:** ![Tim\_Carlton](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim_carlton/32/52835_2.png) [@Tim\_Carlton](https://forum.inductiveautomation.com/u/Tim_Carlton)\ **Post date:** [August 3, 2023, 2:48pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/2 "2023-08-03T14:48:45Z")
Can you create a View in the database? ---
**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:** [August 3, 2023, 3:02pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/3 "2023-08-03T15:02:08Z")
This in not possible with just the Designer. Nothing to stop you from sending the list produced by P as a parameter to qeury W. Honestly though, if you don't need query P without query W, then I would say creating a view in the database itself is probably the best approach, followed by creating a stored procedure in the database. ---
**Author:** ![stan.cook](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/stan.cook/32/10553_2.png) [@stan.cook](https://forum.inductiveautomation.com/u/stan.cook)\ **Post date:** [August 3, 2023, 3:09pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/4 "2023-08-03T15:09:57Z")
I can't see how the "view" option will work. Maybe a limitation of my brain. I did not see a parameter data type option what would take a list of integers (person ID numbers). I thought of that, but did not pursue. Query P is useful by itself. My fallback will be to just embed it in W as a subquery. Just hate having to keep 2 blocks of code sync'ed up if (I mean WHEN) anything changes in the future. Thanks for your input ---
**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:** [August 3, 2023, 3:17pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/5 "2023-08-03T15:17:37Z")
> [@stan.cook](#): > > I can't see how the "view" option will work. Don't confuse Database View with Perspective View. You could then do exactly what you're trying to do in W, where instead of a sub query, you just use the View. ---
**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:** [August 3, 2023, 3:18pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/6 "2023-08-03T15:18:08Z")
> [@stan.cook](#): > > parameter data type option what would take a list of integers Strictly speaking, this is not supported by generic JDBC, and therefore there is nothing in the named query system to accommodate them. It so happens that at least one JDBC driver (PostgreSQL) will accept true java **arrays** (not _lists_) in single parameters, and Ignition's "Prep" queries will pass these correctly. See this topic: > [@Read/Write and Clear from an Array Tag (integer array)](https://forum.inductiveautomation.com/t/read-write-and-clear-from-an-array-tag-integer-array/74199/5): > > Does it work if you convert the list into a jarray first? v = [0,1,2,3] import jarray from java.lang import Integer v\_arr = jarray.array(v, Integer) To be honest I'm not even sure if array columns are supported or not, but see if this gets you to an error somewhere further. { Perhaps we need a feature request for NQs to offer **array** parameters. } ---
**Author:** ![Tim\_Carlton](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim_carlton/32/52835_2.png) [@Tim\_Carlton](https://forum.inductiveautomation.com/u/Tim_Carlton)\ **Post date:** [August 3, 2023, 3:20pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/7 "2023-08-03T15:20:50Z")
Not an Ignition View, a database View. In SQL Server ```auto CREATE VIEW [dbo].[TaskTable] AS SELECT Column1, Column2, Column3 FROM dbo.Task INNER JOIN dbo.User ON Task.UserId = User.UserId GO ``` Then you create a named query on the TaskTable database view and treat it like it was a table. ---
**Author:** ![stan.cook](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/stan.cook/32/10553_2.png) [@stan.cook](https://forum.inductiveautomation.com/u/stan.cook)\ **Post date:** [August 3, 2023, 4:29pm UTC](https://forum.inductiveautomation.com/t/can-a-namedquery-be-embedded-in-another-namedquery/77371/8 "2023-08-03T16:29:52Z")
Thanks, I did understand it was a DB view you were talking about. The query P is a recursive query that I send a group ID to and it gives me the people in that group or any subgroups. Putting that in a view definition is more than I can wrap my head around at the moment. More thought required on my part.