When I try to save new marc records in master I get the following error: Software error: Field 100 must have indicators (use ' ' for empty indicators) at /home/nengard/kohaclone/C4/Charset.pm line 142 Now, my 100 field has indicators filled in so I don't understand the error and I can't save my records because of it. Also, if this is an error that others are going to see it should be a JS popup type error - cause the only way out of this is go back. Regardless, I can't save new records at all in master using Marc21 right now.
I just saved two simple marc records with leader etc., 100 and 245 in master without problems? Second indicator of MARC 100 should be blank? Tried 0 and 1 for the first one; no problem?
Okay, when I do an original record it has no problem - when I pull in from Z39.50 (2 different titles, 2 different targets) it has this problem and both times the indicators are filled in. I'm wondering if this is an authority linking issue.
I looked into this. After a Z39.50 search, where I "import" a biblio, and upon "save" this error happens. Reason: With AutoCreateAuthorities = generate AND LinkerOptions containing broader_headings Workaround?: Once I remove broader_headings I can save. But I don't know the ramifications of removing broader_headings. See C4/Linker/Default.pm code related to linking a matched authority. I don't have enough knowledge of indicators to know why they are being copied, but maybe it is related to other side-effects for searches or such.
I think this might be a dup of bug 8552. Or vice versa - not sure.
I'm having a problem with subfields. If a 100, 650 or 700 has a subfield attached to it, when I try to save the record, the 100, 650 and 700 are erased. Now, if these fields do not have a subfield attached to them, they save just fine. So yesterday I was cataloging a score with 100 a Beethoven, Ludwig van, 100 d 1770-1827. When I deleted the d field, it saved the 100 field fine. But when I tried to save the record with both the a and d field, Koha "erased" the field. Is anyone having this problem? Thanks, Pam
(In reply to comment #5) > I'm having a problem with subfields. If a 100, 650 or 700 has a subfield > attached to it, when I try to save the record, the 100, 650 and 700 are > erased. Now, if these fields do not have a subfield attached to them, they > save just fine. > > So yesterday I was cataloging a score with 100 a Beethoven, Ludwig van, 100 > d 1770-1827. When I deleted the d field, it saved the 100 field fine. But > when I tried to save the record with both the a and d field, Koha "erased" > the field. > > Is anyone having this problem? Thanks, > > Pam What version of Koha Pam?
3.08.01.000
Any new development on this? I am having problems on copy cataloging, Z39.50, original cataloging, literally all cataloging. If I can't save subfields, I'm going to have to do some pretty severe workarounds. Maybe even go on vacation. Cataloging is all I'm doing this year.
(In reply to comment #8) > Any new development on this? I am having problems on copy cataloging, > Z39.50, original cataloging, literally all cataloging. If I can't save > subfields, I'm going to have to do some pretty severe workarounds. Maybe > even go on vacation. Cataloging is all I'm doing this year. Do you have a test server? Have you tried with a newer version of 3.8.x (3.8.4 is out now) Do you have a support company or did the install yourself? I haven't run into this bug myself, nor had it reported to me by any of the Libraries we support, so I personally am unlikely to be working on a fix for it.
> Do you have a test server? Not that I know of. If you e-mail hnear@cornish.edu she's our Director and Systems Librarian. > Have you tried with a newer version of 3.8.x (3.8.4 is out now) We have not yet been scheduled for an update. So no. > Do you have a support company or did the install yourself? We're with BywaterSolutions. They handle all this stuff. >I haven't run > into this bug myself, nor had it reported to me by any of the Libraries we > support, so I personally am unlikely to be working on a fix for it. That's too bad for me, I guess.
Pam, ByWater created this bug report as well as Bug 8552, which I believe is the same thing. We are looking into it but do not have a solution yet. We have had several reports of this problem from libraries on 3.8.1 through 3.8.3. Thanks, Melia
Thanks! :D
Created attachment 12050 [details] [review] Bug 8447: Make sure we have enough subfields for broader_headings Thanks to wajasu for providing the debugging information, as I cannot seem to duplicate the problem, even seeing where it could come from.
Created attachment 12070 [details] [review] Bug 8447: Make sure we have enough subfields for broader_headings Thanks to wajasu for providing the debugging information, as I cannot seem to duplicate the problem, even seeing where it could come from. Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Here is a user case that caused the problem (for historical reference and testing for QA) In admin set sysprefs AutoCreateAuthorities - generate BiblioAddsAuthorities - allow dontmerge don't LinkerModule Default LinkerOptions broader_headings Catalogueing -> Z3950 search Subject [Bible.] Library of Congress[x] Import the one with: 1 Corinthians : 2005 080282577X (cloth:alkpaper) 2005052170 Edit koha itemtype books 942c, and 003 Save ( and get software error mentioning indicators) BEFORE jcamins 1st 8447 patch for corrected "map" translation: 630 ? - SUBJECT ADDED ENTRY--UNIFORM TITLE a Uniform title Bible. p 1 Corinthians p blah blah v Form subdivision blah blah Apply 8447 patch and Save ( now SAVE WORKS ) AFTER jcamins 8447 patch for corrected "map" translation: 630 ? - SUBJECT ADDED ENTRY--UNIFORM TITLE a Uniform title Bible. 6 9 (RLIN) 137 l Language of a work t Title of a work v Form subdivision x General subdivision y Chronological subdivision z Geographic subdivision wajasu Note: I recall that thre might be other bugs that this fix applies to.
Created attachment 12074 [details] [review] Bug 8447: Make sure we have enough subfields for broader_headings Thanks to wajasu for providing the debugging information, as I cannot seem to duplicate the problem, even seeing where it could come from.
Created attachment 12075 [details] [review] SIGNED-OFF-Bug-8447-enough-subfield broader headings/ error indicators Here is a user case that caused the problem (for historical reference and testing for QA) In admin set sysprefs AutoCreateAuthorities - generate BiblioAddsAuthorities - allow dontmerge don't LinkerModule Default LinkerOptions broader_headings Catalogueing -> Z3950 search Subject [Bible.] Library of Congress[x] Import the one with: 1 Corinthians : 2005 080282577X (cloth:alkpaper) 2005052170 Edit koha itemtype books 942c, and 003 Inspect 630 before the save. Save BEFORE patch, we get softeare error (indicators...) AFTER patch (It SAVED!!!) If you inspect 630, the fields that were there before you saved are still therem but with an added link in subtag 9. Note: Code in Linkers other that Default doesn't use the map transform so i didn't attempt to test their behavior. wajasu
bag - jacamins an I found some other broken behavior, which he fixed, and I tested. Signed Off.
Created attachment 12076 [details] bug8447autolinkauthorityfix.png correctly saved 630 field For reference, bug8447autolinkauthorityfix.png shows the finally save 630 field, with all the original fields preserved, and the link added (subtag 9).
(In reply to comment #18) > bag - jacamins an I found some other broken behavior, which he fixed, and I > tested. > > Signed Off. Great - I tested this with the original bug reporters data - so I'm glad that you found outlying issues. Great! and glad to see a new signed off test. I'll retest on the original data and provide a second signoff if it works. -Brendan
I suspect this fix will fix bug 8552 as well. Since, it was subject headings like fields being broken.
*** Bug 8552 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > (In reply to comment #18) > > bag - jacamins an I found some other broken behavior, which he fixed, and I > > tested. > > > > Signed Off. passing QA, nice work people! $ koha-qa.pl testing 1 commit(s) (applied to commit 60790d0) * 1decc86 Bug 8447: Make sure we have enough subfields for broader_headings C4/Linker/Default.pm * C4/Linker/Default.pm OK
Patch pushed to master (problem not reproduced by me, though. I just checked nothing was broken)
I was just able to save my 650 with a subfield of x. So, is everything fine now? Thanks, Pam
(In reply to comment #25) > I was just able to save my 650 with a subfield of x. So, is everything fine > now? Thanks, You would have to ask your service provider. It is very unlikely that you are running master, as master is intended for development only and not production use.
Pushed to 3.8.x, will be in 3.8.5