MARC Report 251: Problems resolved

  • Some users with version 250 reported seeing the message “Unicode error in string” pop-up when navigating to certain records. This was caused not so much by a unicode error as by an improperly coded exception handler in our unicode normalization unit. Fixed in 251. If you have version 250, be sure to update to 251.
  • User-customized sets for the RDA Appendix I and Appendix J relationships were not being initialized correctly when the validation engine started. Fixed in 251.
  • There was a problem with certain first words in titles wrongly triggering a filing indicator error message. Typically, the words in question would end in a diacritic, which when removed, would leave behind a stem which then matched an existing initial article in our list. (For example, after removing ő from Első, the result is Els, which matches an initial article). Fixed in 251.
  • The addition of language support to the RDA relationships in 250 inadvertently introduced a problem whereby the dash in “on-screen presenter” triggered a validation error. Fixed in 251.
  • When RDA relationship validation was introduced (version 244), we excluded almost all of the linking fields (760-785) from the default setup 1). However, an option for the user to enable this validation was included. Unfortunately, support for that optional validation was never added to our validation module. This oversight is remedied in 251. Validation for the linking tags is still disabled by default, but if the user enables it, it will now function properly.
  • The validation table distributed with version 250 was not up-to-date regarding the repeatability of a few content designators: $s Version (in Titles and added entries), $d Date of meeting or treaty signing (in X10/X11), and 856 $u (Uri). All are now repeatable. Fixed in 251.
  • We've had some reports (and have witnessed the same behavior ourselves) that, when using the 'Related Records' view, attempts to fetch a record from LC using a permalink sometimes fail (when they should succeed). We've looked at the code, talked to experts at LC about this, and so on. Its possible this problem might be related to LC being too busy at certain times of the day to handle all the requests it receives (as you will notice if you try to access the online catalog in the afternoons, for example). As an attempt to workaround this problem, we've added a second fetch attempt to this module–if the permalink download fails, then MARC Report will retry the request using one of LC's Z3950/SRU interfaces.
  • In MARC Global and MARC Review there was a problem with the 'Scratch' review feature (added in 248 ). If a scratch review was loaded, run, and then saved (ie. generating a 'normal' saved review), then any subsequent edits to the Reviews table would result in all such 'scratch' reviews that appeared there being deleted as soon as the Save button was pressed. Fixed in 251.
  • In MARC Global, when using the 'merge-list' feature, we discovered that the merge would not take place if the pattern tag was repeated in the target records. For example, we had a merge-list where the first column contained a control number to match against an 035; but if the 035 was repeated, and one of the 035s in the record did not match (which would normally be the case), then no merge would occur based on the 035 that did match. Fixed in 251.
  • The Import from text utility would fail to identify the marcbreakr format if the leader row (ie. the one that begins =LDR ) contained trailing blank spaces. Fixed in 251.
1)
with good reason, as the subfield $i strings present in our research sample–the LC database–were not related to RDA
251/current_issues.txt · Last modified: 2021/12/29 16:21 (external edit)
Back to top
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki