# Issues Moving Dataset to DB

**URL:** <https://forum.inductiveautomation.com/t/issues-moving-dataset-to-db/101867>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [February 4, 2025, 8:26pm UTC](https://forum.inductiveautomation.com/t/issues-moving-dataset-to-db/101867 "2025-02-04T20:26:52Z")\
**Posts on this page:** 1\
**Showing post:** 18

<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:** [February 5, 2025, 6:53pm UTC](https://forum.inductiveautomation.com/t/issues-moving-dataset-to-db/101867/18 "2025-02-05T18:53:22Z")

</div>

If you use a competent database backend, you can do essentially unlimited rows per batch with just one `?` placeholder per column:

> [@Stored Procedure call overhead-way to batch?](https://forum.inductiveautomation.com/t/stored-procedure-call-overhead-way-to-batch/96630):
>
> We have a data query application that calls a stored procedure within a script, potentially 90 times for a single execution. There appears to be some overhead associated with the creation and execution of the stored procedure, making the script itself take sometimes 10+ seconds. Without moving away from the stored procedure approach, is there a way to batch these calls to optimize performance? Generically, we pass a couple of values to the stored proceudre, then write the response to a plc…

{ Sorry, Jason, MS SQL Server is **not** a competent database. }

---

_[View the full topic](https://forum.inductiveautomation.com/t/issues-moving-dataset-to-db/101867)._
