Database Driving Provider Issue

I have three database schemas and three database driving providers on one gateway. Each database driving provider has a unique name, database, and driver name.

My issue is that I am getting common alerts across the different databases. When I look in the alert_log table in my database I see alerts coming in from every database driving provider.

Is this a bug or am I missing the purpose of the provider?

have you looked at the advanced properties of the alert notification profile? you can add filters to the system or to the path. you will probably need to have more than 1 if you are trying to separate your projects.

Thanks. That fixes the alerting problem but the root problem remains. It also affects my Alarm History page, etc. Now if there were a way to filter the database driving provider…that’s why I thought you select what database you want when configuring the provider.

what you might need to look at is setting up a separate sqltags provider for each project. then you can filter by just the system on alarm tables and alert storage profiles and the like.

for instance you have a project for customer 1 and another project for customer 2.

setup a sqltags provider for customer 1 and a separate sqltags provider for customer 2.

then you have your separate database for each.

then you can setup authentication and auditing profile for each.

then when you setup your alert notification profile you choose the database for that customer and then filter the alerts by system, which would be something like SQLTags.Customer 1 (where Customer 1 is the name of the sqltags provider).

now on all of the alarm tables and such you can filter by system also, which would show all of say customer 1’s tags in alarm, instead of system wide tags in alarm. then if you needed to filter by location you could use the tag path.

Thats the best way that I have seen so far to segregate customers , but someone may know something better.

I do have a separate auditing, authentication, and sqltags provider for each. That is where I’m getting stuck. Shouldn’t that prevent the tags from co-mingling in all the databases?

I will try to filter as much as I can, but I don’t think this will solves the problem efficiently…


Yes, I think you’re fighting a bit against the grain on this one. In many ways SQLTags tries as hard as possible to unify everything, instead of seperating it. You’d like each provider to be a sandbox, whereas the system trying to merge all the providers into a unified model. For example, an expression tag in one provider could reference or write to a tag in a different provider.

Setting up filters is probably about your only option. Though, I’ll think about this situation a bit more as we work on 7.3, which includes some work on SQLTags.


I kind of like having the ability to access all of the tags. its easy to pop in a filter by system on the alert profile and also in the alarm tables…

it gives you alot of flexibility down the road.