Customized output from:
Document Release Date: April 2015 Software Release Date: April 2015 |
|
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.
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.
© 1994-2015 Hewlett-Packard Development Company, L.P.
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.
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. |
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."
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"
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
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.
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
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
© 1994-2015 Hewlett-Packard Development Company, L.P.