GHC:op_id greater than 10 characters stored incorrectly in db

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

Description:
Bug Report Form for Issue 16384-9714

Module: Cataloging/catjob
Release(s): reported in 7.1.0; replicated in 7.2.0
Server Platform(s) affected: Solaris/all
PC O/S (if this is PC specific): n/a
Browser type & version (if WebVoyage): n/a

Expected Results: If an operator specifies an operator id that exceeds the allowed number of characters, catjob 13 should return an error message indicating that the id must not exceed X number of characters, and give the operator a chance to re-key in the information.

Actual Results: If an operator specifies an operator id that exceeds the allowed number of characters, catjob 13 completes successfully but stores either a null value or an abbreviated version of the id entered.

Workflow Implications: The update operator id on any records touched by this run of global headings change will be unreliable or absent.

Replication steps:
Make a change in an authority record that has associated bibs.
Run catjob 11.
In Cataloging, go to File>Global Headings Change.
Click the plus sign next to the heading.
For the record that displays underneath, check the Process box.
Run catjob 12.
In the global headings change queue in Cataloging, click on the Preview button to see the bibs to be changed.
Run catjob 13, specifying an operator with more than 10 characters (the db limit).

--> if the id specified has 11 characters, the id stored will be null. If it has 12 or more characters, it will store the 12th character on (for example, 'supercalifragilistic' is stored as 'agilistic'); if it is 9 characters or less it is stored/displays fine; and if it is 10 characters, it is stored correctly in the db, but displays in Cataloging as the operator id followed by the time/date stamp (all in the Operator field).

Resolution:
Fixed in Voyager 8.2.2.

• Article last edited: 3/4/2015