# system.tag.storeTagHistory - Creating New Tag IDs and acting funny

**URL:** <https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-new-tag-ids-and-acting-funny/20132>\
**Category:** Ignition\
**Created:** [October 12, 2018, 9:50pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-new-tag-ids-and-acting-funny/20132 "2018-10-12T21:50:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![robwarren](https://avatars.discourse-cdn.com/v4/letter/r/7cd45c/32.png) [@robwarren](https://forum.inductiveautomation.com/u/robwarren)\
**Post date:** [October 12, 2018, 9:50pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-new-tag-ids-and-acting-funny/20132/1 "2018-10-12T21:50:28Z")

</div>

Hello,

I’m using the system.tag.storeTagHistory function, and I’m getting some somewhat unexpected behaviors.

When I first started messing with it, I noticed that every time I ran the function that it was creating a new tag ID in the sqlth\_te table. It appeared that it was because the new value was being stored outside of the [create / retired] range. This is undesirable because I want to write values to these tags many times, and I don’t want to blow up my sqlth\_te table with tag counts.

My solution for this was to manually update the sqlth\_te table to give the specific tag that I’m working with a created datetime of 0 and a retired datetime of ~2099. This seemed to be working pretty well for the one tag I was looking at.

I then added a new tag, and I wrote a value, and then I updated the created / retired values.  
Next, I wrote a value to that tag (using system.tag.storeTagHistory) again, and it created a new entry into my sqlth\_te table with a restricted created / retired range.  
Then, I wrote several more values to my tag on different dates, and they all went under the new tag.

So, my question is, how does the system.tag.storeTagHistory function actually work, and is there a way that I can get it to work without creating tons of additional tagid’s in my sqlth\_te table?

If I need to do some manual configuration of the tags when I create them, I can do that and just make it part of my process. I just need to know exactly what to do, and it would be nice to know why…

* * *

Here is some of my data out of my DB:

These results are all based on querying the same tagpath.

select  
top 1000  
\*  
from  
sqlth\_te  
where  
tagpath like ‘some/tag/path’

![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/e/e9c1f6d4cb74e145f87d1b97fc16ab904be4bd1a.png)

select  
top 1000  
\*  
from  
sqlt\_data\_1\_2018\_09  
where  
tagid in  
(select id from sqlth\_te where tagpath = ‘some/tag/path’)  
order by t\_stamp DESC

![](https://us1.discourse-cdn.com/inductiveautomation/original/2X/e/e6daeb7cd296f22e78f499cf0b8fc25a1e3b0706.png)

PS: Now, I just wrote a value with a DateTime before the t\_stamp of the 2.22 value, and it created tagid 1026 with a created time of 1536987600000  
and retired time of 1539101125010

Also, Running Ignition v. 7.9.2

---

<div class="post-metadata">

**Author:** ![robwarren](https://avatars.discourse-cdn.com/v4/letter/r/7cd45c/32.png) [@robwarren](https://forum.inductiveautomation.com/u/robwarren)\
**Post date:** [October 19, 2018, 2:09pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-new-tag-ids-and-acting-funny/20132/2 "2018-10-19T14:09:26Z")

</div>

Having worked through this pretty extensively with support, here is what seemed to be the solution:

It was recommended that I update to 7.9.9 because there were some changes to the storeTagHistory() function somewhere in there. No problem, upgrade completed.

Since I am storing tag history from before the point was created, it is EXPECTED that a new entry in the sqlth\_te table be created. This will have a created date of your storeTagHistory() t\_stamp, and a retired date of the created time of the original historian entry.

This was my initial thought, which was why I thought updating one of the te entries to a created t\_stamp of 0 would solve the problem.

It turns out that I was correct, and if you are going to be storing history on tags from before they were actually created in the system, you can set the original tag created time to zero. After updating this sqlth\_te created t\_stamp to zero (or whatever earliest past date you will be using) you have to restart the Tag Historian.  
This can be accomplished by restarting the entire gateway or changing something on the Historian Provider and applying the changes. I simply changed the description on the webpage and hit save changes, checked the log to confirm that it restarted the historian, and commenced testing my points. After this process, storeTagHistory() hasn’t created any additional sqlth\_te entries.

The Caching is mentioned in the storeTagHistory() documentation, but I didn’t find it particularly clear and I certainly didn’t understand what I needed to do in order to use it properly.  
[https://docs.inductiveautomation.com/display/DOC79/system.tag.storeTagHistory](https://docs.inductiveautomation.com/display/DOC79/system.tag.storeTagHistory)

I hope this helps someone in the future (if so please like it so I know my time wasn’t wasted in posting the update / solution)

And big thanks to the support team.

-Rob W.