Bug 28128 - Uploading Process of New Cataloging Records Stalls When 952 $9 Is Filled In
Summary: Uploading Process of New Cataloging Records Stalls When 952 $9 Is Filled In
Status: RESOLVED DUPLICATE of bug 28152
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: 20.05
Hardware: All All
: P5 - low critical with 10 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-11 22:46 UTC by Charles Kelley
Modified: 2022-06-27 23:08 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 Charles Kelley 2021-04-11 22:46:52 UTC
About three months ago, my library moved its Koha ILS to a new machine. The transition was not ideal but it was smooth enough.

    We still catalog a bit on the old machine and last week we extracted and uploaded a bunch of records to the new machine. The upload process stalled.

    After days of trying to find out why the uploading process would stall, I noticed that the 952 $7 in a few records was miscoded as a 952 $9 instead. Once I reverted the 952 $9 to 952 $7, all was well.

    This also happened when a transfer record had a 999 field. If the record number in 999 $c and 999 $d did not exist, the uploading processing would stall. So I deleted the 999 fields or corrected them to what was in the other copy of the ILS; and again all was well.

    I have been reading online about this phenomenon and I haven't found a reason or solution to the stall. Mind you, other operations continue to run: the editing of existing records and the entry of new records; circulation; calendar changes, etc. It's just the automatic record uploading through the user interface that stalls.

    Well, here are two possible solutions: check for 952 $9 fields and 999 fields in the records that are to be uploaded. They may be the source of stall. Their presence may not be the only source, mind you, but their presence is a possibility.

    P. S. It would be nice if instead of stalling, the uploader would write the MARC record to some sort of upload log with a reason; and then try uploading the next record.
Comment 1 Elaine Bradtke 2021-04-13 18:03:21 UTC
We have had uploads fail due to one faulty record (which passed muster in MARCedit as a valid MARC record). It took me hours of splitting to find the bad record.

 I would like to add my support to this statement "It would be nice if instead of stalling, the uploader would write the MARC record to some sort of upload log with a reason; and then try uploading the next record."

Even spitting out the bad record to a log file without a reason, and moving on with the import would be a vast improvement.
Comment 2 David Cook 2022-06-27 00:47:15 UTC

*** This bug has been marked as a duplicate of bug 30739 ***
Comment 3 David Cook 2022-06-27 23:08:58 UTC
Actually it looks like this is a duplicate of bug 28152

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