Is there a reason that there is no “id” index on the alert_log table? In our legacy system we look at alarmlog_ndx to determine the row we are updating. Is it ok to add an id index to this table?
I’ll have to check, but it is probably an oversight.
Feel free to add an auto-increment ID to the table.
If you do create it by hand, I’d recommend using the same convention that FactorySQL used (“tablename_ndx”). It is almost certainly an oversight (although, it might have been on purpose, since an INT id doesn’t get used much with alerts- they’re always queried/ordered based on timestamp), and if/when we fix it, it will use that scheme.
Regards,
I am really new to this, but I ran into this with the example ignition project and the alarm table.
The ID column looks important if you want to easily ACK a single row in the alarm history table. Of course there are a lot of other mismatches to the original alert table format compared to the new, but that just helped me understand it a little better by getting it to work.
General question, is there a way to get it to stop popping up the error boxes during design mode? This gets annoying when you are trying to look through the window elements and there is an error on a query that keeps firing.
Thanks,
Darren
You can keep the error box from popping up every time a new error triggers by minimizing it. Just click on the arrow in upper right of the window that points down and left. The error box will then happily sit in your task bar without bothering you until you open it again.