• Article Type: General
• Product: Voyager
• Product Version: 8.2.0

Description:
Bug Report Form for Issue 16384-10593
Module(s): Cataloging
Server platform(s) affected: Linux
PC OS (if applicable): n/a
Browser & version (if applicable): n/a
Release(s) replicated in: 7.2.1

Expected results: In a MFHD record with no history, you should see the message “Unable to retrieve record history” when clicking on the History tab in the record, and then be taken to the empty History tab and allowed to continue working in Cataloging.
This IS what happens when working on a Solaris server platform.

Actual results: When working on a Linux server platform, instead of the message “Unable to retrieve record history” when clicking on an empty history tab, you get run-time error 440, followed by run-time error 65099. Then the client hangs and has to be shut down from the Task Manager.

Workflow implications: Disruptive, and operators can lose work if they haven’t saved other open records when this happens.

Replication steps:
1. Using a database hosted on a Linux server, log in to Cataloging and open a Holdings record with no history.
2. Click on the History tab.
3. You will see run-time error 440: automation error, followed by run-time error 65099; then Cataloging will hang and you will need to close it from the Task Manager.

Other information: If you repeat the replication steps using a database hosted on a Solaris server, instead of run-time errors, you are alerted that the system is “unable to retrieve record history” and allowed to continue working in the client.

Workaround: Operators can click “Save to DB” before opening History tab to generate an “Update” entry in the history, so that it is not empty.

Resolution:
Fixed in the catsvr for 8.2.0.

• Article last edited: 3/5/2015