To reproduce in KTD: - Find a record in the staff client - Save the record as MARCXML - Import the record with bulkmarcimport.pl: perl /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -v -m --file my_record.marcxml - Log into the database and look at the last record added: MariaDB [koha_kohadev]> select * from biblio_metadata where biblionumber = (SELECT max(biblionumber) FROM biblio_metadata)\G *************************** 1. row *************************** id: 442 biblionumber: 444 format: marcxml schema: MARC21 metadata: <?xml version="1.0" encoding="UTF-8"?> <record xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd" xmlns="http://www.loc.gov/MARC21/slim"> <leader>00080 a2200049 4500</leader> <controlfield tag="005">20250124080114.0</controlfield> <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">444</subfield> <subfield code="d">444</subfield> </datafield> </record> timestamp: 2025-01-24 08:01:14 record_source_id: NULL 1 row in set (0.000 sec) Only MARC fields 005 and 999 are present.
I can confirm the the dubious behavior on 24.12.00.005
That is... not really good? Upping severity. Is this limited to MARCXML or also happens with .mrc?
I only tested MARCXML.
I just rechecked and I think the problem was sitting in front of the keyboard :) The command was missing the value for -m which then defaults to ISO2709 perl /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -v -m --file my_record.marcxml' It should be perl /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -v -m=MARCXML --file my_record.marcxml
Oh my! I had -m, but I didn't actually provide a value for it... *facepalm*
You know what? Better this way than it being a bad bad bug :)