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.
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.
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.
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.
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.
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.
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.
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.
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 
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.
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.
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.
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.