Play the following backup/restore game: 1) create two empty instances, A and B, both in the UNIMARC flavour; 2) populate A with ten bibliorecords, two of which with associated items; 3) create a backup from A so that only UNIMARC records having items are exported; the backup indeed contains only two records; 4) import the backup into instance B; 5) contrary to expectations, see that B now contains two biblio records but no items associated to them. If I inspect the records in the catalog of B, I see that they are void of the field 995 (https://wiki.koha-community.org/wiki/Holdings_data_fields_%289xx%29#UNIMARC_Holding_field.2C_3.2_default_-_field_995). However, the records staged in the temporary area of B during import phase do have that field. So it seems that the UNIMARC item field is correctly fetched when importing the backup in the stage area, but discarded when the staged records are pushed in the catalog. This bug is dangerous because it prevents the backup/restore procedure to work. Backup/restore is a necessary step to preserve the biblio archive in case of hardware/software failures. So this bug may cause a permanent loss of the archive.
What is a backup in this context? I have exported the records then imported them in a fresh DB. I got: MARC staging results : Processing bibliographic records 1 records in file 0 records not staged because of MARC error 1 records staged Did not check for matches with existing records in catalog 5 item records found and staged then: MariaDB [koha_kohadev]> select count(*) from items; +----------+ | count(*) | +----------+ | 5 | +----------+ All looks good for me (items are displayed on the detail page of the bibliographic record). Tested with UNIMARC.
(In reply to Giuseppe Ciaccio from comment #0) > So it seems that the UNIMARC item field is correctly fetched when importing > the backup in the stage area, but discarded when the staged records are > pushed in the catalog. I think I found why. The push to catalog is not allowed because the items have the same barcode which must be unique in catalog.
Created attachment 86216 [details] a test backup containing 10 bibliorecords and 21 items (UNIMARC) Try with these records. On my koha installs (two ones at the moment, a 17.11 and a 18.11), importing this batch results into 10 records in the catalog but no items. The batch however contains 21 items, and these are visible in the record copies left in the stage area.
(In reply to Jonathan Druart from comment #1) > What is a backup in this context? Backup is: saving data away, and use them to restore a service after a catastrophic failure. In koha I would export records to a file, and import them again in case the original archive is lost. > I have exported the records then imported them in a fresh DB. > I got: > MARC staging results : > Processing bibliographic records > 1 records in file > 0 records not staged because of MARC error > 1 records staged > Did not check for matches with existing records in catalog > 5 item records found and staged > > then: > MariaDB [koha_kohadev]> select count(*) from items; > +----------+ > | count(*) | > +----------+ > | 5 | > +----------+ > > All looks good for me (items are displayed on the detail page of the > bibliographic record). > > Tested with UNIMARC. Could you also search the OPAC interface and see the items from there too? I tried the import of the UNIMARC batch now attached to this bugreport. From the admin interface, Home -> Tools -> Stage MARC records for import. Leaving all settings to default. Output is: MARC staging results : Processing bibliographic records 10 records in file 0 records not staged because of MARC error 10 records staged Did not check for matches with existing records in catalog 21 item records found and staged (consistent with the content of batch) Then I click on "Manage staged records" and, in the subsequent page, leave all settings to default and click on "Import this batch into the catalog". Output is: Completed import of records Number of records added 10 Number of records updated 0 Number of records ignored 0 Number of items added 0 Number of items replaced 0 Number of items ignored because of duplicate barcode 0 Clearly the items have been ignored; confirmed by searching the OPAC: it finds the biblio records but no items.
(In reply to Fridolin SOMERS from comment #2) > (In reply to Giuseppe Ciaccio from comment #0) > > So it seems that the UNIMARC item field is correctly fetched when importing > > the backup in the stage area, but discarded when the staged records are > > pushed in the catalog. > > I think I found why. > The push to catalog is not allowed because the items have the same barcode > which must be unique in catalog. Ok it is not that. Does instances A and B have the same branches ? for items homebranch and holdingbranch
(In reply to Fridolin SOMERS from comment #5) > (In reply to Fridolin SOMERS from comment #2) > > (In reply to Giuseppe Ciaccio from comment #0) > > > So it seems that the UNIMARC item field is correctly fetched when importing > > > the backup in the stage area, but discarded when the staged records are > > > pushed in the catalog. > > > > I think I found why. > > The push to catalog is not allowed because the items have the same barcode > > which must be unique in catalog. > > Ok it is not that. > Does instances A and B have the same branches ? > for items homebranch and holdingbranch Bingo! The two instances A and B have different branchcode and it seems that instance A refuses to import items whose branchcode does not match. Verified by manually editing subfields 995$b and 995$c -- replacing some of the original branchcodes with the one of instance A, then A will import only those items with matching branchcodes.
I guess there is the error in a lost output. We would be able to handle that better on top of bug 22417.