Keep tag history when moving tag

I have to move a local tag provider to a remote tag provider. But I cant figure out how to keep the tag history intact.

All help is gratefully received☺️


The only way I know is to edit the records so that records tied to the old TagId point to the new TagId.

In editing the tag ids, I'd be concerned about not retrieving history from these old records since the date range in your new tags will start after the old history was created. I would rather rename the tag path in the table for the old tags. You'll also have to relink them to the new tag provider as well. Definitely something to test in a dev gw first

Umm, isn't that a given? It's not a new tag, its the same tag moved to a new location. the old Id will have already been retired (at least it should have been), so telling the system that the old data belongs to the new tag seems like the better approach. IMO

But the datetimes of the old tag's data will have timestamps before the start date of the new tag

Nevermind, changing tagids in the sqlt_data tables should be ok. I just wonder if you need to change the created date of the new tag as well or if that's just not looked at when querying for data

When moving a tag to different folder in the same provider, the old location tag path will have a retired timesamp in _TE table and the new tag path will have a new id. And for keeping the tag history I only need to edit the old tag path matching the new.

But when moving to a new provider, the new tag path in _TE table haveing a new id, also have a new scid.

Do you mean changing all the table names, and scid?

He means just updating the tagid fields in the sqlt_data_... tables to the id of the new tag path in the sqlth_te table.

The data tables are not tag-provider-aware (or rather, they're made aware of them with the link back to the tag) and hence moving the tagid to a new one isn't going to matter if the new tag is in a different tag provider

I will do a test tomorrow.

Are the queries that Ignition uses for history documented somewhere?

Not that I know of

One word of caution, if you change the tagid values in the sqlt_data_... tables, you will lose any related information associated with that tag in regards to scan class info/execution as that is all stored in sqlth_scinfo and sqlth_sce tables. You may also now have records in your sqlt_data_... tables that are older than the execution records in sqlth_sce since it is now associated with a new scan class id.

A record of executions of scan classes, defined in sqlth_scinfo . This table is primarily used to determine when the system was running correctly. The end_time of an entry is updated, as long as it falls within 2*rate of the last execution. If not, a new entry is made, and data queried will be "stale" during the gap.

I think it's likely that this also impacts tag history calculations, but I'm not certain about that.

Personally, instead of changing the tagid values in the sqlt_data_... tables, I would change the tagpath values in the sqlth_te table to match the new tagpath and then adjust the sqlth_scinfo values (and sqlth_sce table if necessary). Depending on whether or not the scan class info still needs to be related to the old provider, it may necessitate duplicating scinfo and sce records and associate them with the new provider. I know this is a little convoluted. It might not be worth the effort for you, but I wanted to at least call out the pitfalls of changing tagid values in the sqlt_data_... tables.

Edit: I forgot to add, if you are changing the provider, then your drivid will change, so if you change tagid values in the sqlt_data tables, you will likely end up with partitions holding data that do not match the partitions for the new provider (records in the sqlth_partitions table). You have this same problem if changing the tagpath values. It's a headache to properly adjust when moving data between providers...

1 Like