Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems? Running the following query: SELECT GROUP_CONCAT('<a target="_blank" href=\"/ cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=',biblionumber,'\">',biblionumber,'</a>' SEPARATOR ', ') AS BibNums, EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM biblioitems GROUP BY Id HAVING count(Id) > 1; finds ~0.1% of our total catalogue with orphans -- often, but not quite always, they are consecutive biblionumbers leading me to think that this happens during cataloguing (but there seems to be no rhyme nor reason as to how it happens, we cannot purposefully duplicate the error.) It's fairly trivial to correct with a " DELETE * FROM biblioitems WHERE biblionumber=123456; " but I'd like to stop it from happening in the first place. Thanks for any suggestions, Paul
Hi Paul,
From how I read this report it returns records with matching Ids (i.e. Control numbers) I don't think Koha enforces unique control numbers.
-Nick On Wed, Apr 30, 2014 at 10:03 AM, Paul A <paul.a@navalmarinearchive.com>wrote:
Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems?
Running the following query:
SELECT GROUP_CONCAT('<a target="_blank" href=\"/ cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=',biblionumber,'\">',biblionumber,'</a>' SEPARATOR ', ') AS BibNums, EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM biblioitems GROUP BY Id HAVING count(Id) > 1;
finds ~0.1% of our total catalogue with orphans -- often, but not quite always, they are consecutive biblionumbers leading me to think that this happens during cataloguing (but there seems to be no rhyme nor reason as to how it happens, we cannot purposefully duplicate the error.)
It's fairly trivial to correct with a " DELETE * FROM biblioitems WHERE biblionumber=123456; " but I'd like to stop it from happening in the first place.
Thanks for any suggestions, Paul
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Nick Clemens Quechee & Wilder Libraries Nick@quecheelibrary.org http://www.QuecheeLibrary.org Q (802) 295-1232 W (802) 295-6341
Paul A schreef op wo 30-04-2014 om 10:03 [-0400]:
Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems?
You're going to have to define what an orphaned biblioitem record is, because that SQL query doesn't seem to do anything that I'd relate to that term. Do you mean duplicate biblios? All it's doing is finding the first biblionumber of a set where members have the same 001. This could just be cataloguing the same thing twice, or records with badly generated 001 entries, or something along those lines. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
At 10:51 AM 5/1/2014 +1200, Robin Sheat wrote:
Paul A schreef op wo 30-04-2014 om 10:03 [-0400]:
Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems?
You're going to have to define what an orphaned biblioitem record is, because that SQL query doesn't seem to do anything that I'd relate to that term. Do you mean duplicate biblios?
Sort of... sorry to be vague, so here's an example, the tail of the query (simplified to remove the html: mysql> SELECT GROUP_CONCAT(biblionumber SEPARATOR ', ') AS BibNums, -> EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM biblioitems -> GROUP BY Id HAVING count(Id) > 1; +---------------------+--------------+ | BibNums | Id | +---------------------+--------------+ [snip] | 22969, 19151 | 8914106 | +---------------------+--------------+ 31 rows in set (0.89 sec) gives me 2 biblio numbers (22969, 19151), both for John Toland's book "The flying tigers" which has the Library of Congress 001. A search in the staff page and the OPAC confirm that we only have one -- both show "The Flying Tigers / (Record no. 22969)" If I search for the other number as cgi-bin/koha/catalogue/search.pl?q=biblionumber=19151 in the staff page I get "No results found No results match your search for 'biblionumber=19151' in NMA Catalog." BUT... if I specifically go to /cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=19151, I get a biblio that our cataloguers either overwrote or deleted or whatever... And, because it's not "findable" in the staff page, it cannot be deleted without direct intervention in the MySQL db. I called it an "orphaned biblioitem" because, without looking for that LoC 001 in biblioitems, I would have had no clue that an unused record was "floating around."
All it's doing is finding the first biblionumber of a set where members have the same 001. This could just be cataloguing the same thing twice, or records with badly generated 001 entries, or something along those lines.
I'm convinced that your thought "cataloguing the same thing twice" is correct -- quite often our cataloguers use Z39.50 to update/overwrite a biblio, but they swear blind that they always delete any previous record that still appears after re-indexing. That's why I'm intrigued about these "orphans" Thanks for your interest and best regards -- Paul
Paul, I can confirm something along the lines of what you are seeing. I've never been sure if this was cataloger error or Koha error though. What I've seen is that there is a row (i.e. biblionumber) in the biblio table but no corresponding biblionumber row in the biblioitems table. exists in biblio but not in biblioitems. Sounds like you are saying that you have a value in biblioitems for a biblionumber but not in the biblio table. My first instinct is that this would be a delete gone bad. or a merge gone awry. Perhaps starting there? I'm curious though if the biblionumber that you are not finding exists in the deleted biblio table??? -joy On Wed, Apr 30, 2014 at 7:22 PM, Paul A <paul.a@navalmarinearchive.com>wrote:
At 10:51 AM 5/1/2014 +1200, Robin Sheat wrote:
Paul A schreef op wo 30-04-2014 om 10:03 [-0400]:
Can anyone please suggest where I could start looking in the code for what might cause orphaned biblioitems?
You're going to have to define what an orphaned biblioitem record is, because that SQL query doesn't seem to do anything that I'd relate to that term. Do you mean duplicate biblios?
Sort of... sorry to be vague, so here's an example, the tail of the query (simplified to remove the html:
mysql> SELECT GROUP_CONCAT(biblionumber SEPARATOR ', ') AS BibNums, -> EXTRACTVALUE(marcxml,'//controlfield[@tag="001"]') AS Id FROM biblioitems -> GROUP BY Id HAVING count(Id) > 1; +---------------------+--------------+ | BibNums | Id | +---------------------+--------------+ [snip] | 22969, 19151 | 8914106 | +---------------------+--------------+ 31 rows in set (0.89 sec)
gives me 2 biblio numbers (22969, 19151), both for John Toland's book "The flying tigers" which has the Library of Congress 001. A search in the staff page and the OPAC confirm that we only have one -- both show "The Flying Tigers / (Record no. 22969)"
If I search for the other number as cgi-bin/koha/catalogue/search. pl?q=biblionumber=19151 in the staff page I get "No results found No results match your search for 'biblionumber=19151' in NMA Catalog."
BUT... if I specifically go to /cgi-bin/koha/cataloguing/addb iblio.pl?biblionumber=19151, I get a biblio that our cataloguers either overwrote or deleted or whatever... And, because it's not "findable" in the staff page, it cannot be deleted without direct intervention in the MySQL db.
I called it an "orphaned biblioitem" because, without looking for that LoC 001 in biblioitems, I would have had no clue that an unused record was "floating around."
All it's doing is finding the first biblionumber of a set where members
have the same 001. This could just be cataloguing the same thing twice, or records with badly generated 001 entries, or something along those lines.
I'm convinced that your thought "cataloguing the same thing twice" is correct -- quite often our cataloguers use Z39.50 to update/overwrite a biblio, but they swear blind that they always delete any previous record that still appears after re-indexing.
That's why I'm intrigued about these "orphans"
Thanks for your interest and best regards -- Paul _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Joy Nelson Director of Migrations ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Office: Fort Worth, TX Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>
participants (4)
-
Joy Nelson -
Nick Clemens -
Paul A -
Robin Sheat