Choosing to Import a Local Catalog record in Z39.50 will create a duplicate record

Bug #1317170 reported by Erica Rohlfs
62
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Low
Unassigned

Bug Description

Evergreen 2.4.6, 2.5.3b, 2.6.0

Within the z39.50 interface, if the cataloger has the Local Catalog selected as one of the services the following causes a record duplication:

1. Conduct a z39.50 search
2. Select the bibliographic record that is attached to the native-evergreen-catalog service
3. Click Import

The record will import into the catalog, causing a duplicate record (same database ID, too).

There may be instances where a library will need to re-import a Local Catalog record. However, this feature currently lacks a safeguard to prevent the accidental re-importing of existing records. There may be libraries not entirely familiar with the interface or who do not have the Service column exposed in the results list and click Import based on the record quality.

From discussion with Bill Erickson:
“When the ability to search the local catalog was added, primarily as a way to simultaneously check for the presence of existing records, no protections were added to prevent an existing record from being re-imported. There are some collision protections / warnings built into the z39 record import APIs based on the TCN, but those are largely ignored now that most (?) people use the database ID as the TCN value. New records coming into the system won't have a database ID (and thus no TCN), so no collisions on TCN occur.”

The ability to view Local Catalog records is highly valuable. However, this feature should also include some form of safeguard, letting users know that they are getting ready to re-import a record from the Local Catalog.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Low
tags: added: z3950
Andrea Neiman (aneiman)
no longer affects: evergreen/2.9
Revision history for this message
Elaine Hardy (ehardy) wrote :

This still occurs in 3.8. PINES does not use the database ID as the TCN. We retain the OCLC number as our TCN.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.