Records with no 901 values
This bug report was converted into a question: question #229221: Records with no 901 values.
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.
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://
Jeff Godin (jgodin) wrote : | #1 |
Jason Stephenson (jstephenson) wrote : | #2 |
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 : | #3 |
Sharing a post Galen Charlton made on #evergreen IRC recently for users wishing to fix this problem.
http://
Additional reading about what causes this:
http://
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 : | #4 |
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(
OR (XPATH(
Galen Charlton (gmc) wrote : | #5 |
it's also in commit 2bdb74056cfe
Dan Scott (denials) wrote : | #6 |
And commit 77ac8a925ba5
Changed in evergreen: | |
status: | Confirmed → Invalid |
I believe we encountered this as well, and unintentionally created a (semi-?)duplicate bug. See bug 927900 for more details.