[Bug 30043] New: Malformed records shown as not existing
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Bug ID: 30043 Summary: Malformed records shown as not existing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs@lists.koha-community.org Reporter: magnus@libriotech.no QA Contact: testopia@bugs.koha-community.org I just had a case where a batch MARC import script (not part of Koha, but maintained separately) had put some records with an empty 942 field into the database. The MARCXML looked something like this: <datafield tag="887" ind1=" " ind2=" "> <subfield code="a">x</subfield> </datafield> <datafield tag="942" ind1=" " ind2=" "> </datafield> <datafield tag="950" ind1=" " ind2="k"> <subfield code="a">y</subfield> </datafield> When trying to view these records, the following message was displayed: The record you requested does not exist But all the data were in the biblio, biblioitems, biblio_metadata tables. It was not possible to view the the record in the editor either. Would it be possible to catch this error and say something like "The record you requested has fatal errors" instead of telling the user it does not exist? Relevant code in catalogue/detail.pl: 78 my $record = GetMarcBiblio({ biblionumber => $biblionumber }); 79 my $biblio = Koha::Biblios->find( $biblionumber ); 80 $template->param( 'biblio', $biblio ); 81 82 if ( not defined $record ) { 83 # biblionumber invalid -> report and exit 84 $template->param( unknownbiblionumber => 1, 85 biblionumber => $biblionumber ); 86 output_html_with_http_headers $query, $cookie, $template->output; 87 exit; 88 } This reports unknownbiblionumber => 1 when $record is not defined, but it does not differentiate between "biblionumber does not exist" and "biblionumber points to a broken MARCXML record". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 --- Comment #1 from Magnus Enger <magnus@libriotech.no> --- SQL to find and fix records with an empty 942 field: SELECT biblionumber, timestamp, ExtractValue( metadata, 'count( //datafield[@tag="942"] )' ) AS count_fields, ExtractValue( metadata, 'count( //datafield[@tag="942"]/* )' ) AS count_subfields FROM biblio_metadata HAVING count_fields > 0 AND count_subfields = 0; UPDATE biblio_metadata SET metadata = UpdateXML( metadata, '//datafield[@tag="942"]', '' ) WHERE biblionumber IN ( x,y,z ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Pablo AB <pablo.bianchi@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pablo.bianchi@gmail.com --- Comment #2 from Pablo AB <pablo.bianchi@gmail.com> --- We get "The record you requested does not exist ()." on a record we can't reach by searching, only directly. Enger's query does't return any results. Searching the logs I found that with that particular biblio:
AH01215: Use of uninitialized value in join or string at /usr/share/koha/lib/Koha/Item.pm line 1043.: /usr/share/koha/intranet/cgi-bin/cataloguing/additem.pl, referer: https://mykoha/cgi-bin/koha/cataloguing/additem.pl?biblionumber=51135
Although [that line](https://github.com/Koha-Community/Koha/blob/22.05.x/Koha/Item.pm#L1043) is only for display purpose only, seems related with custom subfields, and we found a lot of issues having 952 with other custom subfields (..., y, z, α, β, γ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org