[Bug 28323] New: Invalid record in sample data leading to error when displaying
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28323 Bug ID: 28323 Summary: Invalid record in sample data leading to error when displaying Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: victor@tuxayo.net QA Contact: testopia@bugs.koha-community.org Strk̆v̜elser illustreret af Jean Anderson dansk udgave ved Lis Engel [overst̆telse ved Jesper Langer] staff://cgi-bin/koha/catalogue/detail.pl?biblionumber=369 opac://cgi-bin/koha/opac-detail.pl?biblionumber=369 ========= error ============ Invalid data, cannot decode metadata object (biblio_metadata.id=368, biblionumber=369, format=marcxml, schema=MARC21, decoding_error=':8: parser error : PCDATA invalid Char value 31 <controlfield tag="001">00aD000015937</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ============ Here is some analysis by Caroline ============ I can't find the exact problem with record 369, but it's definitely problematic, even MarcEdit won't open it I can view it with a command line tool that I have Problem record : https://snipboard.io/paTtIK.jpg the error messages seem to point to the control fields 001, 004 (which doesn't exist in MARC21 afaik), and 008 Compared with a healthy record : https://snipboard.io/XFZ5VN.jpg In fact, there are a couple more fields in the problem record that dont exist in MARC21 : 021 (should probably be 020), 245$d (should probably be 245$c?), 245$f should be dates The fact that indicators are all 00 is also wierd... anywho, I think there is probably a character at the beginning of the record that is messing up everything else tuxayo: does this look like a legitimate record to have in sample data? Because real world data can be weird ^^ tuxayo: Or is this worthless and should be removed from sample data? caroline: I think it should be removed.... I mean it's just sample data and this one is clearly a problem Unless it was there for a specific purpose like you suggested it causes problem when searching for danish documents too :/ Advanced search > Language Danish > Search > Error ====== issue with search of Danish records ======= - OPAC - advanced search - Language dropdown => Dansk - search - error Actually it's just that it redirects to the record page -- 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=28323 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28323 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Joubu, can you tell if the record is there for a purpose? Maybe the unit tests? I keep stumbling on it too when I need to reindex Elasticsearch. -- 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=28323 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Yes, 369 is known to be buggy. I think we should keep it. -- 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=28323 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Is there a more elegant way then deleting it by SQL when you need to reindex? -- 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=28323 --- Comment #4 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Katrin Fischer from comment #3)
Is there a more elegant way then deleting it by SQL when you need to reindex?
IIRC bad records are skipped, it should not prevent other records to be indexed. -- 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=28323 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #4)
(In reply to Katrin Fischer from comment #3)
Is there a more elegant way then deleting it by SQL when you need to reindex?
IIRC bad records are skipped, it should not prevent other records to be indexed.
You are right - I had issues there in the past, but testing it just now it seems to work ok. -- 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