5 Replies Latest reply on Mar 13, 2017 2:54 PM by Nick Apostolakis

    mm Tables have dev and production locations

    Nick Apostolakis

      I finished an overhaul of our 9.3.1 model in Dev then copied everything over to production with the right owner (DBO), everything works good, now the DBA's have asked to change the owner from DBO to GIS.

      I exported the xml's in order then copied everything over again to the new Electrical.GIS. schema, next I edited the xml and replaced anything .DBO. with .GIS. and ran the import.

      again everything works good but when running tools like QA/QC I noticed references to the old schema.

       

      Where I found out that I made a mistake was I also copied across the mm tables as the SDE user instead of deleting them and re creating them.

      Now I have the MM_CLASSMODELNAMES, MM_FEILD MODELNAMES AND MM_SNAPPING tables that have references to my Dev, DBO and GIS schema in them.

       

      Working in the DEV environment first and with ESRI's help I was told to delete the mm tables then recreate them and then re-apply the modelnames, properties and snapping xml to repopulate them.

      The problem I have is the modelnames and properties load good but the snapping xml just stops working at about 15%(I left it over night and it did nothing), then program has not crashed it just doesn't do anything, I can cancel it and the program just goes back so you could load another.

      when I check the snapping table it has 7 records and 8 & 9 are there but empty, there should be several dozen entries.

      I am not sure why it is hanging.

      I guess this is the right procedure to do this but could a person use SQL on the server to delete the old schemas from the table without deleting the entire table?

        • Re: mm Tables have dev and production locations
          Stephen Pursley

          Hello Nick,

           

          It appears that Esri has opened a ticket for you on this issue earlier today. I have just made some updates to the case notes.

           

          We will keep you posted regarding the possibilities here.

           

          Hope this helps.

           

          Cheers,

          Stephen

            • Re: mm Tables have dev and production locations
              Nick Apostolakis

              I think I could do it another way. First copy snapping elsewhere then delete the snapping
              and recreate it then just load the data from the table copied but during the load use sql statement to just load the GIS info.

               

              I tested in dev  deleting the snapping table then recreate it and loaded the data from Production with a query for just GIS schema and it worked fine.

               

              if the theory holds, I should be able to do this with the 3 tables and ignore the xml files all together.

            • Re: mm Tables have dev and production locations
              Stephen Pursley

              Hello Nick,

               

              Thanks for the update. Let us know if that works on your end.

               

              If so, I will provide an update to the Esri-logged ticket.

               

              Cheers,

              Stephen

              • Re: mm Tables have dev and production locations
                Nick Apostolakis

                Everything was working in 9.31 except that during a QAQC check the old schema would still show. during our recent upgrade we dropped the system tables and recreated them in the new 10.21 environment but again the old schema would show during a QAQC check, After some checking I found the problem with the old schema showing when QAQC was run. its funny how things seem easy after you find the answer, the reason I kept seeing the old schema was because, the QAQC displays the alias name and the alias on a few feature classes were just set to the default path at creation hence the old schema. Once I removed pathing and reduced the alias name to the featureclass name there was no more reference to the old schema.