We are looking at doing something like this in the future, but it is not as simple as advanced sql in report writer. Reports run every so often, so if there is bad sql, no huge deal. However, if a user puts bad sql into a advanced alert, that runs on a much more frequent basis, so we need to make sure to put safe guards in place against this.
Understood. You could really shoot yourself in the foot if not careful here. I am kinda doing this already without the nice interface. I can create an empty alert and plug my select statement directly into the AlertDefinitions.TriggerQuery field.
So we are kinda doing it already, but it does have its drawbacks. If someone should open the alert, make a change and save it, it will overwrite my select statement.
So when i do this i save my select statements in text form so i can plug them back in just in case someone changes the custom alert.
But i totally understand the hesitation in implementing it without some kind of logic to make sure we dont hurt ourselves. I just thought it would be nice if there were an interface for it so i would not have to do it behind the scenes and document it.
Perhaps it could simply be implemented with a pop-up disclaimer warning you of the potential conseqences of misconfiguration. This way no new safe gaurd logic has to be developed around it.
Use it at your own risk!!
I too would love this to be able to work.
I have a rather "advanced" alert that I am trying to accomplish. I've written it in SQL, but I can't get Orion to actually trigger an alert off of it.
I've tried creating a blank alert and plugging my select statement into the AlertDefinitions.TriggerQuery field, but with no success.