Following up to Pete's post below (at least on a temp basis), for some of the lessons learned: a) We tried yesterday to set up a new data framework primarily for data input. Pete deleted the 999$ (well intentioned error - it is only "internal" and in hindsight should not be an option to delete within a framework) and immediately had second thoughts, reinstated it and set up the subfields over again. WRONG... this had far reaching consequences. Is it a bug to even be able to delete it if it is so intrinsic to the guts of Koha? b) At that point we started trial import of a couple of books - these created the error messages that started this thread. HOWEVER... the process wrote partial|corrupted data to SQL without any warning whatsoever - in other words the error message appeared part way through writing to SQL. Surely this is also a bug (but I'm not too sure of how to go about wring one up.) We have now had to go manually into the SQL db and remove these records. An added difficulty was that we had to "eyeball" the db, as all Koha (zebra) searches were no longer functional. Then run misc/batchRebuildBiblioTables.pl, then rebuild zebra, etc and we're back in business. All is now working as expected - search functions and staff input. c) "Koha to MARC Mapping" has a very oddball quirk. Having started with 3 errors in "MARC Bibliographic framework test": - homebranch NOT mapped the items.homebranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - holdingbranch NOT mapped the items.holdingbranch field MUST : be mapped to a MARC subfield, the corresponding subfield MUST have authorised value=branches - biblio and biblionumber The biblio.biblionumber and biblioitems.biblioitemnumber fields be mapped to a MARC subfield, we remapped (again - for the umpteenth time) 999$c and $d, but they appear in all three tabs "Biblio", "BiblioItems" and "Items" and every time you edit them in one tab, they disappear from the other two as if unmapped. The end result (or at least where we're at now), is that the biblionumber must ONLY be mapped in the Biblio tab, BiblioItemnumber in BiblioItem tab and ItemNumber in Item tab DESPITE the possibility of doing otherwise - which crashes the "Search" capability .... .... and we've still got the third error in the "Framework Test" despite the system working [apparently] well (the "branches" error has automagically disappeared.) Thoughts? I still don't know why 999 is editable. What *desirable* features can be turned on and off? We have only seen a very time-consuming downside. Best - Paul Tired old sys-admin At 12:41 PM 3/30/2011 -0400, pete huerter wrote:
Yes, I had deleted 999 from our (custom) ACS Books framework, but nowhere else. Is it possible that that could change the "Koha to MARC Mapping", or any of the other frameworks (like default?)
I just noticed that 999.c,d where missing entirely from our "Koha to MARC Mapping", and (I think) this was causing all sorts of errors (adding a biblio fails, searching, ..). I've since added them, and run BatchRebuildBiblioTables.pl.
It seems that we have some bad records that were added yesterday under our ACS Books framework (that did not have 999.c,d set up properly.) I'm thinking of just deleting these because they cause errors in BatchRebuildBiblioTables, and batchRepairMissingBiblionumbers.pl (http://permalink.gmane.org/gmane.education.libraries.koha.devel/5569).
It seems like 999c,d are integral to the functioning of Koha.
Thanks, Pete.
On 30 March 2011 10:06, Paul <paul.a@aandc.org> wrote:
I would appreciate some assistance with biblionumber and biblioitemnumber, given that we can no longer enter new biblios.
Error code is : "Tag "" is not a valid tag. at /usr/share/koha/lib/C4/Biblio.pm line 2848"
That line (under the head : "Internal function to add or update biblionumber and biblioitemnumber to the MARC XML" is the first of these four:
my $new_field = MARC::Field->new( $biblio_tag, '', '', "$biblio_subfield" => $biblionumber, "$biblioitem_subfield" => $biblioitemnumber
What are the values that biblio.pm is expecting, and where exactly are
input from GUI page
?
It seems that the call is based upon biblionumber=0 [which is <10,
On Tue, Mar 29, 2011 at 5:14 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote: they therefore
creating the error according line 2847 : "# biblionumber & biblioitemnumber are in the same field (can't be <10 as fields <10 have only 1 value)"] and seeing as we are using a custom framework (cut down to what we need for cataloguing staff purposes), I need to know what particular line I have set to "ignore" that is creating the error. What "Tag" have I left out?
Can't find anything in the docs on this "Internal function."
Thanks for any pointers,
Hi Paul
Have you messed around with the 999 field and subfields? Specifically breaking their mappings or deleting them entirely?
Chris _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>