I was cleaning up some tags before an upcoming project was deployed, and I noticed that tags that I had deleted from the default tag provider were not retired in the sqlth_te table.
That leads me to my question, what causes a tag to get retired in that table?
Thanks,
Brandon
Tags should be retired in sqlth_te when the associated realtime tag is disabled, deleted, or has history turned off. Unfortunately, there was a bug with this behavior (fixed in a fairly recent version) so it’s possible you’re looking at older records that will not retroactively retired, or even that you’re still on an affected version.
Regardless, non-retired entries in sqlth_te have only cosmetic impact - unless you’re getting to truly ridiculous _te record counts (ie, millions) scanning the _te table is not going to cause historian performance problems.
I’m using version 7.9.7. Was it fixed after that?
I was not worried about that impacts on the historian performance. I was using the count of the non-retired records in that table to keep track of the number of active history tags. Is there another method to quickly get that number (besides going to the gateway webpage)?
Looks like the fix was in 7.9.5 - but if you had records prior to that point, they won’t get retroactively retired. If you aren’t seeing tags get retired in 7.9.7, could you get in contact with support so they can do some triage and file a ticket for us to take a look at?
is there a query we can run on the sqlth_te table to delete the tags and tag history that have been deleted from the project? I have tags that have been deleted in the designer but show up in the list of tags in the easy chart trend page but then there is no data for them which is confusing for our client.
If you get in contact with support they should be able to help you out with this. There’s not really a way to do it with just a query, since the db by definition doesn’t know about your realtime tags, but there are some other methods available that support reps can help you out with.
Unfortunately, there was a bug with this behavior
What excactly was this bug?
We have a project where an extern system looks at the Ignition historical database and extracts data from it.
We need to merge data from the currently active tag ids (non-retired) with the retired tag ids to get the full data range.
From my own research it looks like a tag gets retired not only when disabled, deleted or history disabled, but also if you change the historical scanclass, the datatype or the value mode.
In any case we discovered that some tags have identical data in the sqlth_te table except for the id and both have their retired value = NULL - i.e. two identical tags and neither retired.
Was that the bug?
Thanks.
Sorry I am late to the party,
Just an FYI this was still happening for me at least as far as 8.1.18 and possibly 8.1.21. I changed the way I work since to try and avoid this issue when doing development work
A considerable directory of development tags, since deleted, appear available when I am browsing for tags to add to my trend tool. I am planning to update the DB to retire them all which will be careful surgical procedure.
They have very similar names to the finished product so it causes confusion for people who are not me.
Currently on 8.1.32, haven't tested it recently.