# How should I be calling database queries (INSERT) from tag changes events? **URL:** \ **Category:** Ignition\ **Created:** [August 3, 2023, 2:49am UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327 "2023-08-03T02:49:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [August 3, 2023, 2:49am UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/1 "2023-08-03T02:49:44Z")
I know tag change event scripts shouldn't run for longer than a handful of ms, so direct database queries are out of the question. But what other methods should I use to call database queries, specifically INSERT statements, from a tag change event handler? Using `system.util.sendRequestAsync`? I'd prefer to use tag change events rather that gateway tag change events since I have a lot of UDT instances that include tags that will use this. They won't be running this very often, but for argument's sake, assume that it will. The tag change events essentially logs a record into a table. Related question: is `system.db.runSFPrepUpdate` included in the 'no-go' functions for tag change events? ---
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [August 3, 2023, 6:47am UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/2 "2023-08-03T06:47:15Z")
I use this all over the show by calling `system.util.invokeAsynchronous` from tag change scripts. I know it is expensive to call, but it frees up the tag thread pool. All tag change scripts either execute near instantly, or invoke async. The gateway runs about 430k tags and going strong. ---
**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, 1:38pm UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/3 "2023-08-03T13:38:38Z")
> [@nminchin](#): > > is `system.db.runSFPrepUpdate` included in the 'no-go' functions for tag change events? I would expect it to be fine. (And much less overhead than `system.util.invokeAsynchronous`.) That's essentially what tag history does. You can use `System.nanoTime()` to confirm. ---
**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:** [August 3, 2023, 1:56pm UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/4 "2023-08-03T13:56:10Z")
I wonder if it's worth creating/exposing a worker pool specifically for scripting for this kind of stuff, to minimize thread creation hits by recycling as much as possible. Probably a dedicated facility, so it's easier to troubleshoot if someone mishandles it, but then everyone who gets into advanced patterns doesn't have to worry about creating and managing their own executor... ---
**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, 1:58pm UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/5 "2023-08-03T13:58:47Z")
That's a good idea. ~~Perhaps a gateway-scope version of `system.util.invokeLater()`~~ Something like `system.util.invokeInPool()` with configurable thread pool size? (Then I could drop the faker I put in `later.py`.) The delay option cuts out a lot of excuses for using `.sleep()`, too. Hmmm. I really like this idea, particularly if it coalesces like EDTUtils. I'll add this to Simulation Aids with a conditional load (so it'll gracefully disappear when implemented first-party). I think the default thread pool should be generous--5x CPU cores or so, so that SQL query duration isn't a big deal. { I realized this facility would be super-useful in Vision, too, and definitely needs to be understood as **not** running on the EDT. } ---
**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:** [August 3, 2023, 2:10pm UTC](https://forum.inductiveautomation.com/t/how-should-i-be-calling-database-queries-insert-from-tag-changes-events/77327/6 "2023-08-03T14:10:57Z")
Yeah, I suppose just exposing a Scheduled executor service would kinda trample on gateway timer scripts. So some kind of nicer facility would be good.