I am considering Ignition for a project I will be working on. One of my biggest issues is that if a tag is renamed or moved, the trend data associated with that point gets orphaned in the database. It has been recommended that I name things generic enough so that I don’t need to rename or move them, but its likely it might happen at some point. How are people dealing with this? I’ve thought of writing some code that searches for orphaned trend data, and reassigns if it needed, however I know this isn’t bullet proof.
I can see both sides of the story when a point is renamed or moved, but having the option to keep or orphan the data would be nice.
We have to deal with this on a regular basis. Our solution is to delete the db column that is no longer used when the tag/group item name is changed. We name our tags/group items exactly what they are. I am running over 6,000 sql tags and upwards of 5000 to 6000 group items. It isn’t really a problem. Are you dynamically naming?
Change TAG_PATH in sqlth_te to match the new tag path, and all is well. You will now have 2 entries for the same tag path, but it will grab all the old data still
Yes, Kyle’s right. I would also like to mention that we know this is an inconvenience. I don’t know that we’ll be able to do this automatically (right now moving a tag is basically adding one and removing another, so there’s not really a way to tell they’re related), but we definitely plan on adding tools in the gateway to let you do fix it more easily.
Unfortunately this hasn’t been improved in 7.3. As I mentioned before, a bit part of it comes from the way tag moving is implemented- as an add & then delete. Anyhow, I know you guys don’t care about how it’s implemented, you just want it to work. I’ll try to take another look at what we can do to help this.
Is it ok to delete the new tag that is created when renaming and then edit the original with the corrected tagpath in order to preserve the original tagid?