# Named Query (insert) with multiple Rows created

**URL:** <https://forum.inductiveautomation.com/t/named-query-insert-with-multiple-rows-created/82653>\
**Category:** Ignition\
**Tags:** scripting, perspective\
**Created:** [December 4, 2023, 12:01pm UTC](https://forum.inductiveautomation.com/t/named-query-insert-with-multiple-rows-created/82653 "2023-12-04T12:01:01Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**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:** [December 4, 2023, 12:54pm UTC](https://forum.inductiveautomation.com/t/named-query-insert-with-multiple-rows-created/82653/7 "2023-12-04T12:54:05Z")

</div>

> [@lrose](#):
>
> QueryString parameter not be made to accomplish this

Not securely, no.

Related topic:

> [@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/named-query-insert-with-multiple-rows-created/82653)._