# Optimal solution for having multiple DB queries on tag value change

**URL:** <https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092>\
**Category:** Ignition\
**Tags:** ignition81, namedqueries, scripting\
**Created:** [March 15, 2023, 1:38pm UTC](https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092 "2023-03-15T13:38:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ATech](https://avatars.discourse-cdn.com/v4/letter/a/a88e4f/32.png) [@ATech](https://forum.inductiveautomation.com/u/ATech)\
**Post date:** [March 15, 2023, 1:38pm UTC](https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092/1 "2023-03-15T13:38:15Z")

</div>

Hi!

Trying to find an optimal solution for following:

There are some OPC tags that by default change their values at the same time:  
dateTime  
partCode  
partQuality

The idea is to insert the data as a new row in DB on each dateTime tag value change, but first it is necessary to give each new partCode an unique ID, which must be used for inserting to parts\_history table.

Knowing that it takes time to write to DB it seems that the main issue is the delay which does not allow to run needed Named Queries in a row (presenting them as a short list just for the overview):

1. INSERT INTO parts
2. SELECT id FROM parts
3. INSERT INTO parts\_history

What options are available in this case?  
For example having a Query tag for partID to run on value change script for "3rd Named Query" is not ideal solution since it may cause problems if same partCode comes consecutively.  
Important to note, that these tags are used in UDT and system overall performance should be affected as little as possible.

Any help or suggestions for a proper approach would be greatly appreciated!

---

<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:** [March 15, 2023, 2:01pm UTC](https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092/2 "2023-03-15T14:01:37Z")

</div>

The SQL Bridge Module is what you need for this.  
[SQL Bridge Module - Ignition User Manual 8.1 - Ignition Documentation (inductiveautomation.com)](https://docs.inductiveautomation.com/display/DOC81/SQL+Bridge+Module)  
[About Transaction Groups Video at Inductive University](https://inductiveuniversity.com/video/about-transaction-groups/7.9?r=%2Fvideo%2Fsearch%2F%3Fq%3Dsql%20bridge%26checked_topics%3D)

---

<div class="post-metadata">

**Author:** ![ATech](https://avatars.discourse-cdn.com/v4/letter/a/a88e4f/32.png) [@ATech](https://forum.inductiveautomation.com/u/ATech)\
**Post date:** [March 22, 2023, 10:27am UTC](https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092/3 "2023-03-22T10:27:18Z")

</div>

In this case the gateway tag change script method was used.  
Managed to write Named Queries so that duplicate rows will be not written (in case of script change etc).

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 22, 2023, 12:06pm UTC](https://forum.inductiveautomation.com/t/optimal-solution-for-having-multiple-db-queries-on-tag-value-change/71092/4 "2023-03-22T12:06:57Z")

</div>

If you want to avoid duplicate rows then you must use a primary key that is the natural key of the table or a UNIQUE index. Any other measure is liable to fail. You must set up uniqueness at the db level to really ensure it.