Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    CAT: extra character in 040 $c in auths with 040 $e rda

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

    Bug Report for Issue 16384-17985

    Module: Cataloging
    Release replicated in: 7.2.4 – 8.1.1
    Last version without bug: in versions prior to 7.2.4, creating an authority as described
    in the replication steps did not pull the 040 $e into the authority record.

    Expected results: When creating authority record, no extra characters would be added.

    Actual results: When creating authority from bib record with 040 $e rda, an extra field separator
    character is inserted in the 040.

    Workflow implications: Inexplicable extra character; confusing for staff.

    Replication steps:
    In Cataloging, find or create a bib with an 040 field and add $e rda to the end of it.
    In Options > Preferences > Validation, make sure that Bypass Authority Control Validation is not checked.
    Click Save to DB.
    From Authority Validation screen, highlight a non-existent heading and click on Create Auth.
    Choose an Authority template (the default Auth.tem template shipped with Voyager will
    replicate the issue).
    Note that in the newly created Auth record, there is an 040 with $e rda.
    Note also that there is an additional field separator between the preceding
    $c subfield and the $e subfield (this character is visible as a box on some PCs,
    but invisible on others; if you use your arrow keys in the field to move the cursor back and forth,
    you’ll note that you must arrow twice at the end of the $c to move on).

    Workaround: Save authority record & check for character, or delete the character if visible in the client.

    Other information: Unable to replicate with values other than rda in $e. Saving authority appears
    to remove extra character in most instances, though, customer reports that character
    remains when saved. Able to replicate that behavior inconsistently internally; a second save
    action removes the character if the first does not.

    Fixed in Voyager 8.1.2.

    • Article last edited: 3/4/2015