# \[Feature\] Store Tag History with Overwrite

**URL:** <https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777>\
**Category:** Ignition\
**Created:** [December 17, 2019, 8:48pm UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777 "2019-12-17T20:48:46Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeffrey](https://avatars.discourse-cdn.com/v4/letter/j/d6d6ee/32.png) [@jeffrey](https://forum.inductiveautomation.com/u/jeffrey)\
**Post date:** [December 17, 2019, 8:48pm UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777/1 "2019-12-17T20:48:46Z")

</div>

Would it be possible to add an overwrite option to the system.tag.storeTagHistory function?  
If I try to move some historical data into a tag that already has history in it, the database queries go into the store and forward quarantine because the primary key (t\_stamp and id) of the data is the same as what it is adding. I would like it to clear the history table data for the time period it is transferring in, then bring in the new data.

This would be similar to how the system.tag.configure function has a “m” or “o” option to overwrite the current tag configuration.

---

<div class="post-metadata">

**Author:** ![bill.liu](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@bill.liu](https://forum.inductiveautomation.com/u/bill.liu)\
**Post date:** [February 8, 2023, 10:21pm UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777/2 "2023-02-08T22:21:44Z")

</div>

I have the same problem. The records get quarantined if timestamp is the same. Any of the following methods can solve my problem:

- Option to overwrite previous record for system.tag.storeTagHistory
- Option to throw exception, or disable quarantine for system.tag.storeTagHistory
- Function to remove records from historian by paths and timestamps
- Function to query historian with a list of tags and a list of timestamps, instead of time range, so I can check if records exist before calling storeTagHistory

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 8, 2023, 10:54pm UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777/3 "2023-02-08T22:54:09Z")

</div>

Most databases have the ability to add insert triggers that can handle such conflicts any way you like. If you must. Ignition's store and forward system doesn't really have enough information at all times to deal with this kind of garbage in. Ideally, you should figure out what is producing the duplicates and fix **that**.

---

<div class="post-metadata">

**Author:** ![bill.liu](https://avatars.discourse-cdn.com/v4/letter/b/9fc348/32.png) [@bill.liu](https://forum.inductiveautomation.com/u/bill.liu)\
**Post date:** [February 8, 2023, 11:45pm UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777/4 "2023-02-08T23:45:05Z")

</div>

Thanks, insert trigger sounds like a good idea to get around the problem. However, most timeseries database has the ability to overwrite past values. I hope ignition can support it natively.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 9, 2023, 12:10am UTC](https://forum.inductiveautomation.com/t/feature-store-tag-history-with-overwrite/30777/5 "2023-02-09T00:10:44Z")

</div>

> [@bill.liu](#):
>
> I hope ignition can support it natively.

Ignition isn't a time-series database. It delegates to generic databases, some of which can do this sort of thing for you.