https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34782 --- Comment #1 from Nick Clemens <nick@bywatersolutions.com> --- This routine checks for the existence of a record, however, it does so only using the 001 field and the authorized heading. You may retrieve the record from different sources, with different encodings. What we encountered on a live site was a file import with MARC8 encoding being returned each time for a search of LOC authorities from a UTF8 server - the original wrongly encoded record was returned in place of the correct one from the server every time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34782 --- Comment #2 from Phil Ringnalda <phil@chetcolibrary.org> --- I'm not sure how many of these are readily fixable in a single reworking, but there are several other problems (unsurprisingly, since we're using it as a cache, and cache invalidation is canonically a hard problem): Even using the import batch just means limiting by the hostname of the server. For the two we ship, there aren't collisions because control numbers in the LC NAF start with n and control numbers in the LC SAF start with sh (or sj or gf), but there's no guarantee that holds true for any domain name hosting more than one authority database. You could easily get baffling errors when auths-o-plenty.com happened to have two records with the control number 0001372638648 with the same 100 and everything else different, from two different databases so as far as they were concerned there was no collision. There's also nothing in MARC saying that 001 is unique within a single database. (003)001 really ought to be since they are completely meaningless otherwise, but not 001. Nor does (003)001+1xx define a particular instance of the record: when someone dies and gets the year of their death added to their personal name record, it will also be added to their name in a 500 see-also in the corporate name record for the name of the band they were a member of. If you look for the records on the day that your source is changing them, but an hour before they actually did, you'll be fine for the personal name, since we'll be looking for Timberlake, Justin, 1981-2023 and not confused by Timberlake, Justin, 1981-, but once you looked at the copy of 'NSync (Musical Group) with 500 Timberlake, Justin, 1981-, that's all you will be shown, making you think your source was sloppy and failed to update the see-also. I've actually done that, and wondered what sort of workflow caused the LC to update the main entry a day before they updated the see-also, because by the next day I had a cleaned-up lx2.loc.gov that no longer had an outdated cached copy. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.