Bug 30896

Summary: Running misc/batchRebuildBiblioTables.pl -c fails with error "Running Data too long for column 'lccn'"
Product: Koha Reporter: David Nind <david>
Component: DatabaseAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: dcook, gmcharlt, jonathan.druart, m.de.rooy, nick, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28328
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30739
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description David Nind 2022-06-02 22:53:00 UTC
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.
Comment 1 Marcel de Rooy 2022-06-03 07:09:28 UTC
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')
Comment 2 David Cook 2022-06-03 07:18:33 UTC
(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?
Comment 3 David Nind 2022-06-03 09:17:09 UTC
(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.
Comment 4 Marcel de Rooy 2022-06-03 09:18:24 UTC
(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 ;)
Comment 5 Nick Clemens (kidclamp) 2022-06-03 10:54:14 UTC
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 :-)
Comment 6 Katrin Fischer 2022-06-25 12:49:54 UTC
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?
Comment 7 David Nind 2022-06-28 06:23:33 UTC
WONTFIX maybe, possibly a real edge case having the test data with two 010s.
Comment 8 Katrin Fischer 2023-06-18 13:10:06 UTC

*** This bug has been marked as a duplicate of bug 28328 ***