# \[bug-13267\]Tag history issues **URL:** \ **Category:** Ignition Early Access\ **Created:** [March 21, 2019, 5:38pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532 "2019-03-21T17:38:16Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![cwaddoups](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@cwaddoups](https://forum.inductiveautomation.com/u/cwaddoups)\ **Post date:** [March 21, 2019, 5:38pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/1 "2019-03-21T17:38:16Z")
So this issue is better, but I don’t believe it is completely resolved. For a local history provider everything works as it should, the entries are created in the scid table and history is stored as you would expect, however for a remote history provider the scanclass entry is still not created in the scid table. In order to get the remote gateway to store history I had to create a duplicate scanclass on the local gateway with the same name as the historical scanclass in the remote gateway and assign it to a local tag’s history provider. Once that was done an entry was created in the scid table with that scanclass name and the remote history provider picked it up and stored history as expected. It doesn’t seem as though the remote history provider is able to create the entries in the scid table, but is able to store history once an entry with that scanclass name is present. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [March 22, 2019, 1:25pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/2 "2019-03-22T13:25:42Z")
Make sure you update your designer launcher. I am having similar problems. I updated my designer launcher after applying the latest patch and a lot of my problems are reduced. ---
**Author:** ![cwaddoups](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@cwaddoups](https://forum.inductiveautomation.com/u/cwaddoups)\ **Post date:** [March 22, 2019, 1:37pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/3 "2019-03-22T13:37:59Z")
I updated my designer launcher for my remote gateway and it did nothing to fix the history storage issue. History should be stored regardless of whether a designer is open or not, I would expect this issue to be somewhere in the either the permissions of the database or in the code that creates the entries in the history tables for the tag groups or scanclasses that drive history storage. To test this thoroughly I had removed all of my history tables and enabled history tag by tag to see what created which entries in the history tables and only history enabled on a local tag created those scid entries in the history tables, the remote history provider was able to pick up on the entry and store history once it was created but was not able to actually create an entry in the scid table it looks like. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [March 22, 2019, 1:40pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/4 "2019-03-22T13:40:52Z")
That’s a good point. I just had an issue with UDT’s that was fixed by updating my designer launcher. The issue was with my tags where it was losing them when I renamed them. So basically, the old designer was saving things on the gateway in a way that broke things. The new designer fixed them but I am still having the historical logging issue. I have tried creating new instances of my UDT and they aren’t logging either but they have the icon to say they have historical logging. ---
**Author:** ![cwaddoups](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@cwaddoups](https://forum.inductiveautomation.com/u/cwaddoups)\ **Post date:** [March 22, 2019, 1:44pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/5 "2019-03-22T13:44:28Z")
Updating the designer is probably a good idea anyways, I did have a weird issue with one of my UDT’s where I had some ghost UDT’s that appeared in a folder yesterday. I exported an xml of the folder and could see three entries with the same tag name for the same UDT type. It was a pain to try to fix as I couldn’t delete them since once one was deleted I got an error saying the tag wasn’t there to be deleted for the others. It was a process of deleting the tag and then restarting the gateway and repeating until all ghost instances were clear, then I could recreate the tags that were supposed to be present. Hopefully updating the designer helps with issues like that. ---
**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:** [March 22, 2019, 2:18pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/6 "2019-03-22T14:18:54Z")
> [@\[Bug-13040\]Possible Bug using tag groups to drive history](https://forum.inductiveautomation.com/t/bug-13040-possible-bug-using-tag-groups-to-drive-history/22888/14): > > Make sure you update your designer launcher. I am having similar problems. I updated my designer launcher after applying the latest patch and a lot of my problems are reduced. Just to reduce FUD: Updating the designer launcher wouldn't affect ~~your actual running designer~~ the actual designer that gets launched at all. The designer launchers literally launch a separate process that runs the actual designer, and that actual designer is always "up to date" with whatever the server is delivering. @cwaddoups - I moved your posts on this tag history issue into a new thread, so we can track it as a separate issue. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [March 22, 2019, 2:24pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/7 "2019-03-22T14:24:53Z")
I’m a little confused on the designer launcher. I had an issue where I didn’t update my designer launcher. I renamed a tag. Then I couldn’t delete that tag because it said that the tag didn’t exist and I couldn’t make a new tag with the old name because it said that tag already existed. I updated the designer launcher and rebooted the server. Are you saying that updating the designer launcher isn’t what fixed that issue? If so, the correct understanding is that either the reboot or simply reopening the designer launcher is what fixed it. ---
**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:** [March 22, 2019, 2:32pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/8 "2019-03-22T14:32:46Z")
Rebooting the server is almost certainly the real fix. Updating the designer launcher doesn’t affect any actual code running within the designer. Reopening _the designer_ can sometimes fix issues, but generally not with tags - since tags are executing on the gateway, and especially in 8.0 there’s a very low probability of an issue with tags being “local” to a single designer instance. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [March 22, 2019, 2:38pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/9 "2019-03-22T14:38:06Z")
Thanks for the clarification. This is kind of like some of the funny operator superstitions on how to fix machines where they do a bunch of unnecessary steps and then one that actually fixes the problem 🙂 ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [March 22, 2019, 5:25pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/10 "2019-03-22T17:25:57Z")
Tag history on UDT is working for me now. I think it works in the patch but my config had issues. I did this: disabled my tag history provider removed tag history from my UDT rebooted re-enabled tag history put some tag history on non-UDT tags as a control (worked) added tag history back on my UDT restarted some UDT tags My configuration is identical in designer to how it was before I applied the patch. Only difference is that I unconfigured it, rebooted and then reconfigured it. All that to say that I think the bug is fixed but upgraded systems might have some problems. ---
**Author:** ![cwaddoups](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@cwaddoups](https://forum.inductiveautomation.com/u/cwaddoups)\ **Post date:** [April 9, 2019, 2:29pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/11 "2019-04-09T14:29:04Z")
I was just wondering if we can get a status update on this with the official release of 8.0? With my testing it seems as though history seems to be stored for remote history providers after disabling all my history providers, dropping all the history tables, and re-enabling history, but I still don’t see any entries in the sqlth\_scinfo table for the tag groups that are being used by the remote gateway. ---
**Author:** ![awalker](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/awalker/32/6874_2.png) [@awalker](https://forum.inductiveautomation.com/u/awalker)\ **Post date:** [April 9, 2019, 3:38pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/12 "2019-04-09T15:38:16Z")
Hi @cwaddoups, We have someone working on this currently and are hoping to get it in 8.0.1. Thanks! ---
**Author:** ![Colby.Clegg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/colby.clegg/32/3282_2.png) [@Colby.Clegg](https://forum.inductiveautomation.com/u/Colby.Clegg)\ **Post date:** [April 16, 2019, 11:44pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/13 "2019-04-16T23:44:42Z")
This may just be a misunderstanding. Other difficulties aside, one aspect of remote history storage as it stands is that all values are sent across as “value” timestamp, and as a result, they don’t track tag groups/scan classes remotely. What you should see is that tags are entered into the sqlth\_te table with a scan class id that corresponds to an entry in sqlth\_scinfo for “\_ exempt\_”, for the correct driver id. All tags from your remote system should be in this virtual “scanclass”. Let me know if I’m missing something on my side. We have a few more days to try to make any fixes for the 8.0.1 rc. ---
**Author:** ![cwaddoups](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@cwaddoups](https://forum.inductiveautomation.com/u/cwaddoups)\ **Post date:** [April 17, 2019, 1:24pm UTC](https://forum.inductiveautomation.com/t/bug-13267-tag-history-issues/23532/14 "2019-04-17T13:24:21Z")
That mirrors what we are seeing as well. It appears that it is working as expected then. I do have a couple other issues that I have seen in the past week with the 8.0.1 version I'm using. One I posted about on the forum and it doesn't have any responses yet. The link is below. The other issue that I have seen is on the gateway on my laptop I have a trial version of the gateway running, when I start the gateway in the morning the opc tags (which at this point the devices are not connected) show a status of bad\_trialExpired as expected. When I reset my trial they go to a status of bad\_UnknownPreviousValue, the only way I have found to clear this status is to disable/enable each tag or to restart the gateway. Either way the tag status goes to bad\_NotConnected which is what I would expect it to be once I reset the trial initially. I'm not sure if this behavior is expected or if it is a bug, but it seems off to me. > [@Tag tree historical selected path and easy chart possible bug](http://forum.inductiveautomation.com/t/tag-tree-historical-selected-path-and-easy-chart-possible-bug/24184): > > I know that bug-13023 was fixed last week to populate the selected path in the tag tree when in historical mode, however the path that populates is in a significantly different format than the format in 7.9 and it does not seem to populate correctly when a tag is dragged and dropped onto an easy chart in historical mode. The selected path property in the tag tree reads as follows: 7.9 Path - [databaseName/gatewayName:providerName]tagpath 8.0 Path - histprov:databaseName:/drv:gatewayName:provi…