HP Service Manager

For the supported Windows® and UNIX® operating systems

Software Version: 9.35

Customized output from:

Interactive Applications Upgrade Guide

Document Release Date: April 2015

Software Release Date: April 2015

HP logo

Legal Notices

Warranty

The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

The information contained herein is subject to change without notice.

Restricted Rights Legend

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

Copyright Notice

© 1994-2015 Hewlett-Packard Development Company, L.P.

Trademark Notices

Adobe® is a trademark of Adobe Systems Incorporated.

Java is a registered trademark of Oracle and/or its affiliates.

Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.

Oracle® is a registered US trademark of Oracle Corporation, Redwood City, California.

UNIX® is a registered trademark of The Open Group.

For a complete list of open source and third party acknowledgements, visit the HP Software Support Online web site and search for the product manual called HP Service Manager Open Source and Third Party License Agreements.

 
 
 
 

Interactive Applications Upgrade Guide

Data type mismatches

If the data type of a field in your dbdict does not match the data type of the like-named field defined in the dbdict provided by the upgrade package, the Upgrade Utility cannot merge these dbdicts. For example, if an existing dbdict has a scalar field and the Upgrade Utility attempts to add a structure field with the same name, this discrepancy prevents the dbdict from being updated.

To fix this issue, you can change the data type and the SQL type of the field, and use Complex Update to migrate existing data on that field to the target data type. The following is an example that shows the process of fixing a typical data type mismatch.

Note: The error messages in the except.log file identify each data type by an index number:

Index number Data type
1 number
2 character
3 date/time
4 logical
8 array
9 structure
11 expression

The following table shows a list of data type mismatches that may appear in the except.log file. The data type mismatches are listed for an Oracle database. If you are using an MSSQL or a DB2 database, the actual error message may vary slightly. For example, the following bullet points highlight the different errors in the different databases:

Error message in Oracle: Solution:

dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255)

dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB

dbdict:ocmq, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:svcCartItem, field:bundle.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:svcCatalog, field:access.filter.xml, SQL type is VARCHAR2(40) -- expected to be:BLOB

To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility.

Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager.

dbdict:cm3eventack, field:number, field type is number -- expected to be:character

To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:eventin, field:evnumber, field type is number -- expected to be:character

dbdict:eventout, field:evnumber, field type is number -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:svcCatLanguage, field:catalogid, field type is character -- expected to be:number

This field resides in the catalog structure field of BLOB SQL type. To fix this issue, change the field type to number by using the Dbdict utility.

dbdict:licenseinfo, field:id, field type is character -- expected to be:number

The licenseinfo table is used to track license information by Service Manager server. This issue should be ignored.

dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number

This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility.

dbdict:cm3profile, field:update, field type is logical -- expected to be:character

dbdict:icmenv, field:update, field type is logical -- expected to be:character

dbdict:ocmprofile, field:update, field type is logical -- expected to be:character

dbdict:pmenv, field:update, field type is logical -- expected to be:character

dbdict:rcenv, field:update, field type is logical -- expected to be:character

dbdict:rcenv, field:pmt.update, field type is logical -- expected to be:character

dbdict:rcenv, field:kne.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:sla.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:slor.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:sloa.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:slocat.update, field type is logical -- expected to be:character

dbdict:smenv, field:update, field type is logical -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:FolderRights, field:close, field type is logical -- expected to be:character

The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:probsummary, field:critical.user, field type is character -- expected to be:logical

This issue can be fixed by following the steps in the Fixing the probsummary critical.user field section.

dbdict:FolderRights, field:delete, field type is logical -- expected to be:character

This issue can be fixed by following the steps in the Fixing the FolderRights delete field section.

Fixing the FolderRights delete field

Example: The dbdict for the FolderRights table has a delete field with the "logical" data type. The Upgrade Utility tries to update the delete field with the "character" data type, which has possible values of "always," "never," "workgroup," and "assigned."

  1. In the dbdict for the FolderRights table, add a field named delete.tmp with a data type of character, and update the dbdict.
  2. Log out of the system and log back in.
  3. Make sure that the Complex Update feature is enabled for the FolderRights table.
  4. In the Database Manager, search for all records in the FolderRights table.
  5. From the More Actions menu, click Mass Update.
  6. When you are asked whether you want to update all records, click Yes.
  7. Click Complex Update on the toolbar.
  8. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete field to the delete.tmp field.

    Example:

    if delete in $file=true then delete.tmp in $file="always" else delete.tmp in $file="never"

  9. In the dbdict for the FolderRights table, edit the delete field and add the Type (character) and SQL Type (same as the SQL Type automatically assigned for delete.tmp).
  10. Log out of the system and log back in.
  11. In the Database Manager, search for all records in the FolderRights table.
  12. From the More Actions menu, click Mass Update.
  13. Click Complex Update on the toolbar.
  14. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete.tmp field to the delete field and empty the delete.tmp field.

    Example:

    delete in $file=delete.tmp in $file; delete.tmp in $file=NULL

  15. In the dbdict for the FolderRights table, delete the delete.tmp field.
  16. Log out of the system and log back in.
  17. Test the change by updating records in the FolderRights table and populating the delete field with "always," "never," "workgroup," or "assigned."

Fixing the probsummary critical.user field

Example: The dbdict for the probsummary table has a critical.user field with the "logical" data type. The Upgrade Utility tries to update the critical.user field with the "logical" data type, which has possible values of true or false.

  1. In the dbdict for the probsummary table, add a field named critical.user.tmp with a data type of logical, and update the dbdict.
  2. Log out of the system and log back in.
  3. Make sure that the Complex Update feature is enabled for the probsummary table.
  4. In the Database Manager, search for all records in the probsummary table.
  5. From the More Actions menu, click Mass Update.
  6. When you are asked whether you want to update all records, click Yes.
  7. Click Complex Update on the toolbar.
  8. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user field to the critical.user.tmp field.

    Example:

    if critical.user in $file="true" then critical.user.tmp in $file=true else critical.user.tmp in $file=false

  9. In the dbdict for the probsummary table, edit the critical.user field and add the Type (logical) and SQL Type (same as the SQL Type automatically assigned for critical.user.tmp).
  10. Log out of the system and log back in.
  11. In the Database Manager, search for all records in the probsummary table.
  12. From the More Actions menu, click Mass Update.
  13. Click Complex Update on the toolbar.
  14. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user.tmp field to the critical.user field and empty the critical.user.tmp field.

    Example:

    critical.user in $file=critical.user.tmp in $file; critical.user.tmp in $file=NULL

  15. In the dbdict for the probsummary table, delete the critical.user.tmp field.
  16. Log out of the system and log back in.
  17. Test the change by updating records in the probsummary table and populating the critical.user field with true or false.

© 1994-2015 Hewlett-Packard Development Company, L.P.