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
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.
Yes, 369 is known to be buggy. I think we should keep it.
Is there a more elegant way then deleting it by SQL when you need to reindex?
(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.
(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.