The command line script misc/batchRebuildBiblioTables.plcommand is used after updating Koha to MARC mappings (Administration > Catalog > Koha to MARC mappings). Running misc/batchRebuildBiblioTables.pl -c from the command line (to rebuild the Koha to MARC mappings) with the sample data in koha-testing-data generates this error message: C4::Biblio::_koha_modify_biblioitem_nonmarc(): DBI Exception: DBD::mysql::st execute failed: Data too long for column 'lccn' at row 1 at misc/batchRebuildBiblioTables.pl line 71 To replicate (when using koha-testing-docker and the sample data): 1. From the command line run ./misc/batchRebuildBiblioTables.pl -c 2. Error occurs: C4::Biblio::_koha_modify_biblioitem_nonmarc(): DBI Exception: DBD::mysql::st execute failed: Data too long for column 'lccn' at row 1 at misc/batchRebuildBiblioTables.pl line 71 I identified this when testing bug 30850 (I worked around the issue by using Tools > Batch item modification to delete the LCCN data in 010: created report to list all the record numbers, added MARC modification templates to delete fields 010 $8 $a $b $z, ran batch record modification). I'm not sure whether this is a problem with the table structure, or whether in real life you would have to identify and fix the problematic data for 010.
This might be some schema problem. I found this when running Biblio.t # Failed test 'expected warnings when adding too long LCCN' # at t/db_dependent/Biblio.t line 61. # didn't find a warning # expected to find warning: (?^u:Data too long for column 'lccn') # expected to find warning: (?^u:Data too long for column 'lccn')
(In reply to David Nind from comment #0) > the sample data in koha-testing-data Should that be koha-testing-docker? Do you know which records were triggering the problem?
(In reply to David Cook from comment #2) > (In reply to David Nind from comment #0) > > the sample data in koha-testing-data > > Should that be koha-testing-docker? It should! > > Do you know which records were triggering the problem? I tried to identify, but couldn't determine. I did a report that listed all the LCCN numbers and put into a spreadsheet, but none were longer than 25 characters - biblioitems table, lccn column = varchar(25). But I could have the wrong table.
(In reply to Marcel de Rooy from comment #1) > This might be some schema problem. I found this when running Biblio.t > > # Failed test 'expected warnings when adding too long LCCN' > # at t/db_dependent/Biblio.t line 61. > # didn't find a warning > # expected to find warning: (?^u:Data too long for column 'lccn') > # expected to find warning: (?^u:Data too long for column 'lccn') Maybe I was a bit to quick here with changing the title ;)
Record 72 has two 010 fields http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=72 This makes the LCCN value too long It can cause errors, but I think is useful for testing error handling :-)
010 - Library of Congress Control Number is NR = not repeatable and seems to have a fixed structure (and possibly length): https://www.loc.gov/marc/bibliographic/bd010.html Does this make this a WONTFIX or should we handle things more gracefully?
WONTFIX maybe, possibly a real edge case having the test data with two 010s.
*** This bug has been marked as a duplicate of bug 28328 ***