Records with no 901 values

Bug #798702 reported by George Duimovich on 2011-06-17

This bug report was converted into a question: question #229221: Records with no 901 values.

22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

EG 2.0.6
PG 8.4

Probably a local data issue, but if so not sure how common this might be for other 1.6->2.0 upgrades.

I came across a record without an 901 system generated tag so we looked at how many others were in the system since the 2.0.6 upgrade. We found about 11,000 such records (or about 2% of our bibs):

select id from biblio.record_entry
where id not in (select distinct(record) from metabib.real_full_rec where tag = '901' and subfield = 'c')

Looking at a bunch of these records we can see one common thread is that they have empty 001 tags (no indicators / subfields). A snippet from the Flat Text Editor view of such a record looks like this:

=LDR 00881nam a22001937a 4500
=001
=005 20100520153539.0

If I view and then save the record in the Staff Client, the 001 and 901 values are populated.

Unless otherwise advised, I'll just proceed with re-ingesting them the 2.0 way: http://goo.gl/xFSRm

Jeff Godin (jgodin) wrote :

I believe we encountered this as well, and unintentionally created a (semi-?)duplicate bug. See bug 927900 for more details.

Jason Stephenson (jstephenson) wrote :

I'm going to leave this bug as "new" rather than incomplete, but I think some questions need to be addressed:

1. Is there a solution for this? Is it as simple as reingesting records?

2. Should the upgrade instructions be updated to include that? Have they already?

Michael Peters (mrpeters) wrote :

Sharing a post Galen Charlton made on #evergreen IRC recently for users wishing to fix this problem.
http://paste.evergreen-ils.org/39

Additional reading about what causes this:
http://evergreen-ils.org/irc_logs/evergreen/2012-09/%23evergreen.26-Wed-2012.log?raw

Perhaps we should suggest running this a part of some sort of documentation -- upgrade maybe as optional -- to prompt users who may be behind on fixing this problem?

Because of what I've recently learned, I'm not sure this is a "bug" but rather a problem with past upgrades and local data, but I will defer to one of the more senior Bug Wranglers.

Changed in evergreen:
status: New → Incomplete
status: Incomplete → Confirmed
importance: Undecided → Medium
Ben Shum (bshum) wrote :

Since pastes don't live forever quite yet, adding gmcharlt's query checking for 901c to the bug ticket for history keeping:

-- query to identify all bibs that are missing 901s or whose first 901$c is not equal to the bib ID
-- this *will* take a long time in a big database
SELECT id
FROM biblio.record_entry
WHERE (XPATH('//marc:datafield[@tag="901"][1]/marc:subfield[@code="c"]/text()', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]))[1]::TEXT IS NULL
OR (XPATH('//marc:datafield[@tag="901"][1]/marc:subfield[@code="c"]/text()', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]))[1]::TEXT <> id::TEXT;

Galen Charlton (gmc) wrote :

it's also in commit 2bdb74056cfe

Dan Scott (denials) wrote :

And commit 77ac8a925ba5

Ben Shum (bshum) on 2013-05-19
Changed in evergreen:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions