I like transaction groups.
I can view everything in the designer from one source of truth beyond the PLC.
I have had good results with them.
I believe standard practice is to use transaction groups for robustness.
I see some people are using stored procedures instead. I know that stored procedures run a little faster, around 10ms faster when I tested.
Are there other benefits one way or the other for tracking fault states, production counts, and reject events?
Are there things that are always better in one or the other?
If you the module for transaction groups was bought and paid for you can bet I am using that instead of writing a stored procedure from scratch to emulate what they do for performance - I am not sweating over a 10 ms difference.
With stored procedures sure you can do literally whatever you want, you a have full control of the script which is called and when etc etc. But if all you're doing is tracking historical information, personally transaction groups are one of the right tools for that job and I would just use that (or historian).
This is a fallacy. Because the execution time is directly related to the state of the database and how the procedure is written, as well as many other things such as network latency.
This is also a really hard question to answer. How good at you at your sql for considering all edge cases, for handling errors etc.
Personally, if I can set it and forget it with a built-in ignition module that has been field tested millions of hours collectively by users and fixed by IA, I will trust that over anything I can make on my own assuming the module covers my scenario.
I think:
Troubleshooting stored procedure takes days.
Troubleshooting transaction groups takes seconds.
Creating stored procedures takes days.
Creating transaction groups takes minutes.
Stored procedures let you change previously collected information easier.
Stored procedures let you write to many tables.
Stored procedures can call other stored procedures.
Transaction groups are kind of a linear story from the objects in them to one table.
I also think:
If I am creating an accurate table of events, transaction group is the tool.
If I am working on dynamic scheduling, then stored procedures are preferred.