R/W Access to Internal SQLTag DB AlertExecEnabled Property

A project I’m working on needs the ability to query and disable/enable alert properties for given SQLTags.

Ultimately I think comprehensive internal DB access should be provided with a group of script and expression functions, but lacking that I will just ask for bits and pieces.

See related request http://inductiveautomation.com/forum/viewtopic.php?f=71&t=6833.

BTW - I cannot replicate the former SCADA’s “Disable Alarm” feature, among others, without this level of access. This is more than important, it is imperative.

Are you trying to disable all alarms at once or individually? I suspect that you could change your alert configurations to support this requirement either way. It may be tedious, but should be possible. How many such alerts are set up?

I won’t discredit your feature request, though.

With their old SCADA, they can select an alarm (alert) on their alarm screen, then enter a Ctrl-key to disable or re-enable that alarm. It’s à la carte, one at a time.

They also have a window that keeps track of all disabled alarms.

In my roll-your-own alert table, the tag path is part of the table, making it trivial (with maybe a right click) to access the AlertExecEnabled property, if a function existed that could get/put internal DB SQLTag properties.

So close but yet so far…

You can write to the AlertExecProperty:


You can bi-directionally bind the property to a component… try dragging it on the screen and make a two-state toggle.

Am I missing something?


No, I was missing something. The manual does not mention tag properties in the function call syntax or example. So I can now globally assume whenever tagPath is a function parameter that ALL properties are available to that function? If so, I can work with that. Looking forward to returned datasets for these functions.

Still need the ability to query SQLTag properties based on other SQLTag properties, such as:

Return a dataset (based on a partial or full tagPath), with a list of returned properties I need, where AlertExecEnabled = 0.

I appreciate all you do to make Ignition robust and SI friendly! :slight_smile:

Good, so we’re halfway there. You’re right, you can’t currently search for tags that match a condition, though I’m sure that could be accomodated one way or another.

Yes, a “tag path” is defined as “[Source]Path/Tag.Property”, where source is optional (when in a project- will be set to project default), and property is optional (will be assumed to be Value). So, anywhere you can use tag paths, you can specify properties.

Most properties are writable. Some aren’t, like the current alert state, quality, last change, etc. If you write to a config property, it should change the value and reload the tag if necessary.


Ah, according to this thread, the multi-path compatible function will actually be in 7.2.9.