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.
Can confirm that there is still a bug.
I created new tag providers to help segregate the tags in the Tag Picker from having all the tags in folders in one tag directory originally (learning). Now, when I select a tag, it only can be viewed in the default tag directory that is the tags are no longer historized in.
This forum isn't an official support venue and I'm not an expert in the historian.
Looks like it is still a bug as of v8.1.48.UPDATE: A little bit of testing suggest that the tag is not properly marked as retired if the tag is disabled (not enabled) at the time it is deleted.
For me it creates functional issues for users primarily when using the historical tag browser in the power chart.
I submitted a bug report as a support ticket.
Deleted tags not being marked as retired in sqlth_te table if the tag is not enabled when it is deleted.
Received the responses.
I have confirmed this behavior in 8.1. I am going to create a bug ticket for this issue.
Currently, in 8.3, you cannot delete a disabled tag. If this is an issue for you right now, please upgrade to 8.3.
That feature is intended.
Ignition Database Table Reference | Ignition User Manual
Please let me know if you have any other questions on this issue.
Indeed the behavior is documented, however I expect it is more likely a known artifact or side-affect of implementation rather than intended behavior as I can't see any benefit/utility in this behavior.
It would seem like a natural course of action to disable a tag or UDT instance for a while and verify behavior of the system with the tag/UDT instance disabled and then delete it.
