Right, the database should provide a way to audit activity. FactorySQL itself does not have a place to see that activity, though I wouldn’t disagree with the notion that it might be a good idea.
As for the other point, you ask about if it “got overloaded and chose not to write records”. This situation isn’t as much of an event as it is a state. First off, I should probably mention a bit about how FactorySQL executes: each group executes, and then gets rescheduled after it finishes. So, if a group is set to execute every second, but takes 3 seconds to run, it’s going to effectively run every 3 seconds. So, FactorySQL didn’t choose to not execute those other 2 expected executions, they just weren’t scheduled.
Now, these types of situations are easier to monitor in FactorySQL, as there are a few ways that this is tracked. First off, on the “status tab” of each group, there is information about the last “Execution Duration”- how long the last execution took. This can be useful if the group doesn’t have a trigger, or is triggered but check infrequently, because when a group executes but has nothing to do (because the trigger isn’t active), it takes almost no time.
For further information, you can look at the “System Status” screen under the Connection menu. Look at the “Statistics” panel. At the top there is information about the avg group exec cost, which is the average of all the group execution durations. The normal value for this should be <50ms, though with a lot of groups or depending on the situation, <150ms
isn’t horrible. More than that and something might be up.
The avg. exec delay is how long groups are waiting to execute, should be around 15ms or so.
Group efficiency doesn’t really matter much. However, the Exec queue length should definitely be 0. The system can run fine even if it’s >0, but it would indicate something of an overload. Now, on some system with a lot of groups, if things line up there can be a big burst of activity, and the queue length can shoot up momentarily. So if it’s >0, hit refresh a few times and see if it’s consistent. The queue length is the number of groups who are due to run but are waiting.
Finally, under “Statistic Monitors” right below that information above, you can drill down to a particular group and check statistics for writes to the database, writes to opc, etc. that might help give an idea of how long things are taking.
Hope this gives you some more info to work with.