Records with no 901 values

[George Duimovich]

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)]

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

[Jason Stephenson (jstephenson)]

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)]

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.

[Ben Shum (bshum)]

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)]

it's also in commit 2bdb74056cfe

[Dan Scott (denials)]

And commit 77ac8a925ba5