Duplicate rows SQL data from transaction groups part2

Hello all! I have 10 transaction groups that run from a seperate trigger that is unique to the device. For some strange reason, it enters a duplicate row of the same data when a transaction group is ran. Because of this duplication it shows up in XL Reporter and I'm struggling to find a way to stop this from happening. I know for certain, my trigger is only incrementing once. Any help would be greatly appreciated!


Most likely cause, based on user experiences in this forum:

Check if you defined these transaction groups in an inheritable project, which has two leaf projects.

{ Don't define anything but project library scripts and re-usable UI components in inheritable projects. }

Here is a screenshot of more recent transactions that are being duplicated. The timestamps are pretty much identical

what does the trigger tab look like?

1 Like

Thanks for responding! Do you mind walking me through where to find that info at? I'm not too familiar with that action

Here ya go! I split it in two pics to capture the entire contents of the tab


What is the project name where you are editing/viewing these groups? Look at the inheritance information for the project in the gateway's config page for projects. (Screenshot for us if not obvious.)

If inheritance is involved, the same transaction groups will run in every project that inherits from where they are defined.

If the project is copy of another project, then you can get two of each group running that way, too.

Ah ok, thanks, I see. Well, it looks like we can rule that out since it is set to false. Now, this is a copy of another project that I changed up a ton and renamed everything to suit this project

I would recommend trying to set only execute once while trigger is active, and then change how you are triggering the group.

Our standard practice is setting a tag to 1 (or true) and then having the handshake give feedback for the execution. Then we would have Trigger Condition > is != 0 set to true.

This allows for a clear true or false as well as feedback that is given by the writeback. It will also guarantee you only get one execution per true eval.