# What Causes a History Tag to be Retired

**URL:** <https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933>\
**Category:** Ignition\
**Created:** [July 23, 2018, 3:29pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933 "2018-07-23T15:29:55Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\
**Post date:** [July 23, 2018, 3:29pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/1 "2018-07-23T15:29:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [July 23, 2018, 5:03pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/2 "2018-07-23T17:03:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\
**Post date:** [July 23, 2018, 7:45pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/3 "2018-07-23T19:45:12Z")

</div>

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)?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [July 23, 2018, 8:28pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/4 "2018-07-23T20:28:25Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![joeyjojoshabadu](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@joeyjojoshabadu](https://forum.inductiveautomation.com/u/joeyjojoshabadu)\
**Post date:** [July 24, 2018, 1:51pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/5 "2018-07-24T13:51:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [July 24, 2018, 2:54pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/6 "2018-07-24T14:54:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Esn](https://avatars.discourse-cdn.com/v4/letter/e/91b2a8/32.png) [@Esn](https://forum.inductiveautomation.com/u/Esn)\
**Post date:** [July 1, 2019, 9:49am UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/7 "2019-07-01T09:49:21Z")

</div>

@paul-griffith

> 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.

---

<div class="post-metadata">

**Author:** ![A\_Power](https://avatars.discourse-cdn.com/v4/letter/a/87869e/32.png) [@A\_Power](https://forum.inductiveautomation.com/u/A_Power)\
**Post date:** [April 18, 2024, 12:29am UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/8 "2024-04-18T00:29:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![hhbauss](https://avatars.discourse-cdn.com/v4/letter/h/ecae2f/32.png) [@hhbauss](https://forum.inductiveautomation.com/u/hhbauss)\
**Post date:** [October 24, 2024, 2:09pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/9 "2024-10-24T14:09:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [October 24, 2024, 3:33pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/10 "2024-10-24T15:33:28Z")

</div>

> [@paul-griffith](#):
>
> could you get in contact with support so they can do some triage and file a ticket for us to take a look at

This forum isn't an official support venue and I'm not an expert in the historian.

---

<div class="post-metadata">

**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\
**Post date:** [February 2, 2026, 6:28pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/11 "2026-02-02T18:28:24Z")

</div>

> [@paul-griffith](#):
>
> 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.

> [@paul-griffith](#):
>
> 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

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.

1. Old tags still show as historical tags despite having been deleted.
2. We have had instance where a path was formerly used for an atomic tag with history enabled. Later on that tag is deleted but the path is reused for a UDT instance with member tags. One or more of the member tags has history but the historical tag browser won't browse any deeper than the path for the UDT instance that was formerly used by an atomic tag (since deleted) that had history enabled.  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/1/81372be8aaefbd7666d0dd91437760d3ae6a700b.png)  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/f/1ffaf3f671061970320771157d5d2b0a4321f5b4.png)

---

<div class="post-metadata">

**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\
**Post date:** [February 11, 2026, 4:56pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/12 "2026-02-11T16:56:33Z")

</div>

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](https://www.docs.inductiveautomation.com/docs/8.1/appendix/reference-pages/ignition-database-table-reference#sqlth_te)  
> Please let me know if you have any other questions on this issue.

Indeed the behavior is [documented](https://www.docs.inductiveautomation.com/docs/8.1/appendix/reference-pages/ignition-database-table-reference#:~:text=If%20a%20tag%20is%20simply%20disabled%20and%20then%20deleted), 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.

---

<div class="post-metadata">

**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\
**Post date:** [February 13, 2026, 7:33pm UTC](https://forum.inductiveautomation.com/t/what-causes-a-history-tag-to-be-retired/18933/13 "2026-02-13T19:33:10Z")

</div>

Another update/clarification from IA support:

> The reason that happens is when we disable the tag, the listener actor shuts down. So there is nothing to create the retirement information when we delete it. There is no specific reason but a by product of how the system works.
> 
> We currently have a feature request to fix the way this works, but for now that is how the system works.
