Whilst installing a cumulative patch, the language independent patch installation fails when attempting to load seed data for a table.

Article Id: 8116
Status: Published
Updated On: 14-02-2018 07:56
Legacy Id: TEC1507456
Products:
SUPPORT AUTOMATION- SERVER , CA Service Desk Manager - Unified Self Service , KNOWLEDGE TOOLS , CA Service Management - Asset Portfolio Management , CA Service Management - Service Desk Manager
Issue/Introduction:

This section contains an example symptom and solution, which may be applied to other situations.

In the example scenario, the 14.1.04 cumulative patch is being applied to a 14.1 environment.  There are table customizations present in the associated MDB database.

Example Scenario: 

I'm trying to install 14.1.04 on our current 14.1 advanced availability environment. When I run the setup.exe from RO96941 and go through the wizard the installation starts fine (using MSSQL, not Oracle). The first part -CA SDM language independent patch (T6EE243)- installs fine, but the second step -CA SDM MDB Patch- fails with error "MDBTools install error=1". 

The following relevant messages are present in the "install_mdb.log": 

09-13,12:41:34 ERROR - java.lang.RuntimeException: Unable to migrate: ca_resource_family: please check table schema 
...
9-13,12:42:12 ERROR - MDBTools_0309E - DBDriver failed to install! 
09-13,12:42:12 WARN - MDBTools_0310W - DBDriver installed with one seed data error. 
09-13,12:42:12 INFO - MDBTools_0104I - Total time: 0H:0M:56S. 
09-13,12:42:12 MDBTools install error=1 
09-13,12:42:12 Setupmdb exit /B return code=1

Cause:

The table specified in the "Unable to migrate" ERROR message in the install_mdb.log has one or more custom fields.  In the example scenario, the table is "ca_resource_family".

Environment:

CA Service Desk Manager 14.1 upgrade to 14.1.04 May also be relevant to other CA SDM versions for which cumulative or rollup patches are being applied.

Resolution:

Follow these steps to resolve the problem:

  1. Confirm that the specified table contains custom fields. 
    Note: If there are no custom fields for that table, then the cause of the problem does not match the scenario of this technical document and the resolution would not be applicable.
  2. Archive the data for the custom field(s) of the table.  You could use pdm_extract to achieve this.
  3. Archive the table definition; in particular, save the definition(s) of the custom field(s).
  4. Revert the table to the original (un-customized) version by removing the custom field(s).
  5. Upgrade to 14.1.04.
  6. If necessary, re-create the custom field(s) and  re-load the archived data into the corresponding field(s).

Additional Information:

The information in this article has been included in our product documentation. You can find further details here:

https://docops.ca.com/ca-service-management/14-1/en/implementing/implement-ca-service-management-14-1-04/troubleshooting-ca-service-management-14-1-04-installation