Bug 28323 - Invalid record in sample data leading to error when displaying
Summary: Invalid record in sample data leading to error when displaying
Status: RESOLVED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-11 23:12 UTC by Victor Grousset/tuxayo
Modified: 2023-07-08 14:00 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Grousset/tuxayo 2021-05-11 23:12:06 UTC
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
Comment 1 Katrin Fischer 2023-07-01 09:08:41 UTC
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.
Comment 2 Jonathan Druart 2023-07-04 08:48:47 UTC
Yes, 369 is known to be buggy. I think we should keep it.
Comment 3 Katrin Fischer 2023-07-04 19:52:45 UTC
Is there a more elegant way then deleting it by SQL when you need to reindex?
Comment 4 Jonathan Druart 2023-07-05 09:46:32 UTC
(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.
Comment 5 Katrin Fischer 2023-07-08 14:00:20 UTC
(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.