5 Replies Latest reply on Sep 21, 2015 3:53 PM by dsouzarich

    Moving an old UOM to a new UOMClass

    Rick Davin

      We need to move an existing user-defined UOM to a new UOMClass. Over a year ago we added a UOM to a standard UOMClass. That UOM is used liberally in many attributes and attribute templates in many AFDatabases for a given PISystem. Recently, our engineering team has decided that that particular UOM really belongs in a new UOMClass; hence our need to move it.








      For those who don't know, you can't delete a UOM if it is being referenced in any database by any attribute, attribute template, or table column. Technically you can try to remove the UOM from the UOMDatabase, but an exception will be thrown when you attempt to check-in. This integrity restriction is not limited to PISystem Explorer but built into the AFSDK itself.








      Moving a UOM doesn't seem to be an easy or pretty task. Off the top of my head, I don't think you can strictly move it as much as duplicate it. Here's the steps that I think are required:





      1. Create the new UOMClass.
      2. Create the new UOM named similar to but different from the old UOM.
      3. Loop through every AFDatabase, for every attribute and attribute template that uses the old UOM and change it's UOM to be the new one. Note that in the name of completeness, one should also check the UOM in all lookup tables as well, but we've already verified that this particular UOM is not referenced in any tables (thank goodness!).
      4. Delete the old UOM.
      5. Rename the new UOM to be what the old UOM was.



      The steps I listed above seem about as much fun as chewing on tin foil.  Is there a better way? Is there is easier way?



        • Re: Moving an old UOM to a new UOMClass



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

            • Re: Moving an old UOM to a new UOMClass
              Rick Davin



              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:

              1. to create the new UOMClass with a dummy canonical UOM,
              2.  'move' the old UOM to the new class,
              3. 'change' the canonical UOM for that new class
              4. 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.





                • Re: Moving an old UOM to a new UOMClass



                  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.

                    • Re: Moving an old UOM to a new UOMClass
                      Rick Davin



                      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.  

                      • Re: Moving an old UOM to a new UOMClass


                        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.