# Named Query with Transaction

**URL:** <https://forum.inductiveautomation.com/t/named-query-with-transaction/83999>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [January 9, 2024, 7:20pm UTC](https://forum.inductiveautomation.com/t/named-query-with-transaction/83999 "2024-01-09T19:20:30Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\
**Post date:** [January 10, 2024, 1:36pm UTC](https://forum.inductiveautomation.com/t/named-query-with-transaction/83999/16 "2024-01-10T13:36:25Z")

</div>

He could check the number of expected rows affected with what were actually affected by the prepUpdate, then rollback if they don't match.

Here is a good post to look at  
[Script Benchmarking with Decorators Example - Ignition - Inductive Automation Forum](https://forum.inductiveautomation.com/t/script-benchmarking-with-decorators-example/63507/5)

> [@HelloWorld](#):
>
> Would this not rollback all the ones that raise an exception and commit the ones that do not ?

It's all or nothing with the transaction, it's not individual transactions, it's individual queries inside one transaction, if anything fails everything inside the transaction will rollback unless you break them up into multiple transactions.

---

_[View the full topic](https://forum.inductiveautomation.com/t/named-query-with-transaction/83999)._