# Long last stored procedure execution in ignition **URL:** \ **Category:** Ignition\ **Tags:** database, ignition81\ **Created:** [December 8, 2024, 9:27pm UTC](https://forum.inductiveautomation.com/t/long-last-stored-procedure-execution-in-ignition/99569 "2024-12-08T21:27:39Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![apimente](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/apimente/32/4030_2.png) [@apimente](https://forum.inductiveautomation.com/u/apimente)\ **Post date:** [December 8, 2024, 9:27pm UTC](https://forum.inductiveautomation.com/t/long-last-stored-procedure-execution-in-ignition/99569/1 "2024-12-08T21:27:39Z")
Hi everyone, I need to execute a stored procedure that takes approximately **30 minutes** to complete. I'm looking for the best approach to handle this while avoiding system hang-ups. One option I’m considering is creating a **button** that triggers a function. The function would execute the procedure asynchronously, thus keeping the UI responsive. I’d also need to extend the timeout to **40 minutes** or so to ensure the process completes without interruption. Another option I'm leaning towards is using a **Transaction Group** to handle the execution. This seems like a cleaner solution, but I’d love to hear your thoughts on this. I know the ideal advice might be to optimize the stored procedure itself, but due to **company policies** and other constraints, I'm limited to working with the existing procedure as-is. What do you think? Which method would you recommend? Are there any other alternatives I should consider? Thanks in advance for your help! ---
**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 8, 2024, 9:32pm UTC](https://forum.inductiveautomation.com/t/long-last-stored-procedure-execution-in-ignition/99569/2 "2024-12-08T21:32:01Z")
- You must run this from gateway scope to escape the hard 60-second limit on execution from Designer or Vision Client scope. - You must update your DB connection's own timeout to permit the very long execution time. - You must configure your DB itself to not timeout on this. - It doesn't matter whether you use transaction groups, named queries, or scripted queries. - You probably need to only call this procedure from one place, and ensure it cannot be called multiple times in parallel. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [December 9, 2024, 4:14pm UTC](https://forum.inductiveautomation.com/t/long-last-stored-procedure-execution-in-ignition/99569/3 "2024-12-09T16:14:12Z")
> [@pturmel](#): > > - You must update your DB connection's own timeout to permit the very long execution time. > - You must configure your DB itself to not timeout on this. I would recommend a dedicated DB connection purely to run this and any other long-lived queries with these specific timeout parameters. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [December 9, 2024, 6:04pm UTC](https://forum.inductiveautomation.com/t/long-last-stored-procedure-execution-in-ignition/99569/4 "2024-12-09T18:04:19Z")
I agree with what the others have said. What I think? I think they need to revise the policies because I strongly suspect the stored procedure has built in performance issues. A lot of people make egregious mistakes in SQL and you can pick up massive performance gains by simply optimizing them. One time I rewrote something to do the same thing with the same database in 2 seconds that they were used to waiting 15 minutes for. Bad code should always be refactored imo.