# system.tag.storeTagHistory() Creating duplicate IDs in sqlth\_te

**URL:** <https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-duplicate-ids-in-sqlth-te/93857>\
**Category:** Ignition\
**Tags:** database, scripting, ignition81\
**Created:** [July 29, 2024, 6:16pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-duplicate-ids-in-sqlth-te/93857 "2024-07-29T18:16:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![djs](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@djs](https://forum.inductiveautomation.com/u/djs)\
**Post date:** [July 29, 2024, 6:16pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-duplicate-ids-in-sqlth-te/93857/1 "2024-07-29T18:16:42Z")

</div>

I've been using system.tag.storeTagHistory() to migrate some history from a different platform to ignition. The tags exist in Ignition, but the historical data that I want to store is from a period before the "creation" date of the Ignition tag.

I found that this results in duplicate entries in _sqlth\_te_. There's the original entry, and then there's a new one with the _created_ and _retired_ timestamps matching the start and end of the transferred data.

Before:  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/a/badc63b407b80b08a040acb7812ccfa7df2d4e7d.png)

After:  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/1/e1c67f47861126bc95265228ba6db95513c23346.png)

This is a problem because tag history queries spanning a period of time that includes the _creation_ date will fail to bring in history from both IDs.

I can go around this by manually updating the _created_ timestamp of the tag to an earlier date, however I need to "restart" the Tag History Provider for system.tag.storeTagHistory() to recognize the update. For one tag, doable. For 1000s of tags, quite impractical...

(By "restarting" the Tag History Provider, I mean editing it and saving it on the gateway webpage, which results in _"History sink 'MyHistorianProvider' started successfully."_ and _"Tag history tables verified successfully."_ entries in the log.)

Worst case scenario, I can update the creation timestamps all at once to some arbitrary date in the past, before migrating any data; or I can run a script to fix the duplicate IDs after the fact. But I'd rather not do that if I can avoid it.

My question would be:  
Is there a way to get system.tag.storeTagHistory() to update the _creation_ date rather than create a new id for the tag?  
Or is there a way to "restart" or "clear the cache" on the Tag History Provider through scripting somehow?

I'd appreciate any insight/advice.

---

<div class="post-metadata">

**Author:** ![djs](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@djs](https://forum.inductiveautomation.com/u/djs)\
**Post date:** [July 31, 2024, 2:43pm UTC](https://forum.inductiveautomation.com/t/system-tag-storetaghistory-creating-duplicate-ids-in-sqlth-te/93857/2 "2024-07-31T14:43:52Z")

</div>

For anyone curious. This function called from the gateway scope will "restart" the history provider:

```python
from com.inductiveautomation.ignition.gateway import IgnitionGateway

def restartHist(prov):
	context = IgnitionGateway.get()
	tagHistMan = context.getTagHistoryManager()
	tagHistProv = tagHistMan.getTagHistoryProvider(prov)
	tagHistProv.shutdown()
	tagHistProv.startup()

```

(Be aware that messing with the historian DB tables or SDK can seriously mess up your historian or gateway.) Use at your own risk. Don't use in production.
