As I'm developing and refining tags and methodologies, I wonder what kind of adjustments create new tag id's to an existing tag. While I am concerned about background issues (multiple instances, orphaned remnants, other leftovers I'm not aware of), I'm very concerned about breaking tag history. For example, if I modify the OPC Server or Item Path, will history be disrupted? We deal with lots of UDTs, and I'll make adjustments for scan rates, deadbands, etc. and those do not have an apparent effect.
Is history just linked to the tag id?
Is my concern limited to modifying the tag path/tag name?
What work on tags would cause a lot of background clutter or memory/performance issues?
In my experience, changing the tag path (or name by extension) or toggling history on will generate a new tag id. Scan classes, datatypes, and query mode can be updated in the record while maintaining the same id.
Only changing that ID will "break" history. But it isn't really broken, its just stored under a different tag id.
Tag history does not care about OPC Server or item path.
Even if you were to need to cause a new ID to be assigned to a tag path, it isn't too much work to go back in and syncronize the data records to the new id. The data isn't lost until it is pruned from the DB.
Thank you both for your input. That's what I've been thinking. I did run a test and disable/re-enable the history and it seems like it did hold in the trends. So if something did happen on the back end, it didn't affect the trends, which is my main concern.
Ignition's APIs for history binding or scripted queries take care of tag ID lookups for you, and will use all of them that match the given tag path. A tag ID being retired when a tag's configuration changes is not a problem. Moving or Renaming a tag breaks history.