I would believe the easiet way is to get into PIFD database directly and change the GUID of the UOM Class for that UOM (fkuomclassid on the UOM table). Although I think many OSIsoft folks will not recommend that, I find it the easiest way so far, given the restrictions of all known clients...
That is quite simpler and quicker. Easier? Only if you tread very, very carefully. Otherwise it's like juggling with nitroglycerin.
To compound matters, you know that new UOMClass I mentioned? It seems that the old UOM needs to be the canonical UOM to the new class. So I need this class to exist before I can move the old UOM. Using a similiar technique as you suggested, I discovered I could carefully also switch canonical UOM's. So now my proposal would be:
- to create the new UOMClass with a dummy canonical UOM,
- 'move' the old UOM to the new class,
- 'change' the canonical UOM for that new class
- delete the dummy UOM
I do want to confirm that these unsupported steps do work for my 2.4 test system.
I'll make a pitch to my boss and see how nervous he gets for changing our production systems. Whether or not we go down this route, thanks for a great suggestion.
Can you please explain why you feel it's necessary to create a new UOM class in this case? I suspect there's a reason why you can't (or don't want to) leave the old UOM in the old UOM class..... inquiry mind wants to know.
I will send you a private email listing our justifications, but ultimately it comes down to us making a mistake a year ago. I presume you are interested in business case for why this happens and whether or not you think that OSI should dedicate some resources to providing a better way in the future.
I have just come across an example where we have several development systems, for several development projects, we are all moving to a QA environment and have conflicts and finding issues with each others configuration/naming of UOM's. We are now trying to conform to the ones in the QA system, even if they are named incorrectly, however not had any success in changing them. We are using AF 2.6.
Having removed old versions of databases and removed the UOM in the elements, I still get an error trying to remove a UOM from a class, still finding attributes that I can't easily find.
Are you aware of any issues in 2.6 that you could allude to.