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.
tagpath like ‘some/tag/path’
(select id from sqlth_te where tagpath = ‘some/tag/path’)
order by t_stamp DESC
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