5 Replies Latest reply on Jan 17, 2015 4:19 PM by dmshimself

    Issue upgrading database from v7.6 to v7.7.3.

    Rookie

      Hi all

       

      Just wondering if someone else has come across a similar issue while upgrading versions of service desk before and may know where I may be going wrong.

       

      For a bit of background...

      We're currently using Service Desk v7.6 along with a MS SQL database and are looking to upgrade to v7.7.3. Have downloaded the relevant install media, am following the 773 upgrade document and currently trying to upgrade a development environment as a PoC before looking to upgrade our production environment.

       

      I've run the setup successfully over both the application and web servers as per the documentation, however when it comes to the database upgrade it fails stating that nulls cannot be inserted into pr_title as below.

       

       

      Firstly I restored the DB, had a look at the column in question and spotted that it is set to accept null values.

       

      I then searched through the MetadataManagerLog.xml as the message states and came across the SQL executed just before the error occurs, which shows that the comlumn is set to not accept null values.

       

       

      I haven't seen anything that says I need to upgrade to v7.6.1 or similar first before moving onto v7.7.3. Does anyone know if there is an upgrade path I need to follow before or should I be able to upgrade straight to the target version.

       

      Any help would be greatly appreciated!

       

      Thanks

      John

        • 1. Re: Issue upgrading database from v7.6 to v7.7.3.
          jhackett SupportEmployee

          John,

          I moved this to the Service Desk threads it was in Management Suite.

          Jared

          • 2. Re: Issue upgrading database from v7.6 to v7.7.3.
            ITSMMVPGroup

            I suspect you have been hit by the upgrade resetting attributes back to what it wants them to be, rather than what you have set them to be.  Restore the DB and check the problem/system cause/title attribute in the LDSD object designer.  I suspect that has been changed to be non-database mandatory at some point in the past.  When you do the upgrade LDSD might be setting it back to be database mandatory.  It does the same with some other attributes like cm_title too because mother knows best :-)

             

            The work around is to update that attribute in that table with something innocuous before the upgrade, let the upgrade happen, then go back in and make it non-database mandatory in object designer.  If I am right and this works, do please report this to support as the upgrade shouldn't do this.

             

            something like

             

            update pr_system_cause set pr_title = 'na' where pr_title is null

             

            But then I might be wrong!

            1 of 1 people found this helpful
            • 3. Re: Issue upgrading database from v7.6 to v7.7.3.
              Rookie

              Thanks for the reply. Tried the work-around you've suggested there and the upgrade went through just fine, will however still get this logged with support and see what they come back with.

               

              Thanks again!

              • 4. Re: Issue upgrading database from v7.6 to v7.7.3.
                Jenny.Lardh SupportEmployee

                Hi John,

                 

                Some attributes in the database are set to be mandatory by default and this shouldn't be changed as this is set in the metadata. If you however do change this and make it none mandatory, you will still be able to work with the product.

                However when you run the MDM on the database the MDM will reset this data and set the attribute back to be mandatory as this is coming directly from the metadata.

                 

                When the MDM is run it will create a temp table that it will move all the database to. It will then drop the original table and create a new one from the metadata and move all the data back to this new table. It's when it's moving the data to the new table that you are getting the error message as you have null values in some of the data and the attribute in the new table now is mandatory it cannot insert the null value.

                 

                The recommendation here would be to not change the attribute from the beginning. If you want to allow to save a null value I would instead recommend that you add a default value in to the attribute in form of a '.' or something similar. You can do this in Object Designer.

                This would avoid this issue to happen again in the future.

                 

                Kind Regards,

                Jenny Lardh

                LANDesk Support

                • 5. Re: Issue upgrading database from v7.6 to v7.7.3.
                  ITSMMVPGroup

                  Some personal thoughts from me on that Jenny. 

                   

                  1.  There isn't a publish list of these special attributes that I am aware of.  Even the most careful and patient administrator is going to find it tough to know which ones are safe to change and which ones are not as the product doesn't prevent you from doing so.  So if this the upgrade is going to continue to behave this way, can you see if you can publish a list of these attributes that need attention?

                   

                  2. Product Management have previously confirmed that an upgrade should not change database mandatory properties when these have been set by legitimate use of the design tools.  For example the change note title field can be changed using object designer to be non-database mandatory, so the upgrade should leave it that way.  Why should it need to change it back really as there is no product functionality I'm aware of that needs it to be DB mandatory?

                   

                  3. Errors like this can take a long time to work through for someone who doesn't have considerable historical knowledge of which attributes are special.  If LD want upgrades to become smoother over time, I'd see this particular area as one that needs some thought.

                   

                  Thanks for reading these musings and I'm very aware support cannot make the decisions suggested above, but hopefully they make sense and could be passed on.