system.alert.queryAlertHistory with filtering path

Hi

We are trying to make dynamic alarm display which shows alarms from different paths depending where display is opened. So we have dynamic properties where is path which alarms we want to see.
We tried first to use Path filter in system.alert.queryAlertHistory function but it seems to be filtering always everything or with wildcard nothing? Maybe path contains some special characters or Tags folder which we miss?

Well we decide to use DisplayPath instead Path and first it looked to work well, but then we found out problem when our filtering string contain ä,ö or å characters. Even exact filter string these alarms are filtered out.
Is there any easy way to avoid this problem, these characters are used really often in Finnish language and in localised projects has to use.

BR
Tommi Vahtera
THT Control Oy

I don’t seem to be having this problem.

I made an alarm with the display path: “[tt]Testing this älarm[/tt]”

and set my path filter to: [tt]älarm[/tt] and it filtered correctly.

Perhaps I do not understand what you’re describing?

HI

Our problem occur if Tag name contains Ä or Ö characters.
So we have empty display path inside tags and alarm list show tag name on path.

Br
Tommi Vahtera
THT Control Oy

Hi,

I haven’t been able to reproduce the problem either (important note though: it appears that “displayPath” filtering isn’t working correctly through queryAlertHistory. Right now, the pattern you put in is not being used. So, let’s focus on filtering the path).

Could you post an example of your call to queryAlertHistory? Are your filters using any wildcards?

Also, it might be helpful to try querying the data directly from the database to see if it looks and works like what you expect. The “queryAlertHistory” takes the passed in parameters and builds a SQL query replacing “*” with “%”. So, you can build a similar query and see what the database would return. For example, something like:

system.alert.queryTagHistory(path="*Ä*")

would be equivalent to:

SELECT * from alert_log WHERE path like '%Ä%'

You might find that the path has more data than you expect and that you need to place wildcards in your filter.

If the database does not seem to be returning the correct results, please let us know what the table “Charset” and “Collation” are set to (you can usually find this by going into a table editor).

Regards,

Hi

I made now totally new small project with 2 tags and new alert_storage profile.

Here is screen capture where I have 3 copies of table where every table contains different path filter.
Top of the table is script which is called from event handle of table.

Like you see it is working if I don’t use Ä or Ö in filtering path.
Here is also window attached where is my scripts.

Hope this help


Br
Tommi
example.vwin (23.5 KB)

Hi,

Do you get any results if you open a database browser and search for:

select * from alert_log where path like 'testi2 Ä%'

(Note: make sure the table name is correct for your profile).

What database are you using? Can you track down the charset and collation settings? In mysql, for example, you can do this by selecting “edit table” in the query browser and going to “Table Options”.

I think it must have to do with the database settings, because I mocked up the same thing you did and it worked.

Regards,

Hi

We are using MySQL database.

I got right result when making normal query:
SELECT * FROM alert_log WHERE path LIKE ‘testi2 Ä%’
So I thing Character settings are correct in tables.

Can the problem be in expression LIKE ?
In system.alert.queryAlertHistory expression is ‘=’ not ‘Like’ ?
So it seems to be filtering everything else out.

Br
Tommi

Hi,

No, it is indeed using “like”, so that’s probably not the problem. One thing I just noticed, if you don’t specify a start date, it will use Now-8 hours. So, if your entries are older, they will get filtered by that. Try adding something like: [tt]startDate=“2000-01-01”[/tt] to your query to make sure that’s not the problem.

Regards,

Hi

Problem was in query and also in start date.
So my testing was not working because alarms was older than 8 hours.

In my script I was using filtering string but there was missing “path=” word, so it was totally my mistake.

Thansk anyway…

Br
Tommi Vahtera
THT Control Oy