At 12:52 AM 3/6/2015 +0000, Tomas Cohen Arazi wrote:
I'm not sure what you're trying to do, but items are no longer inserted into marcxml, and to shouldn't be using 3.8. At all.
And at 12:10 PM 3/6/2015 +1100, Bob Birchall wrote: [snip] Items data were removed from the marcxml for performance reasons, at Koha 3.4. Any version above 3.2 should have no 952 data in the marcxml. Tomás, Bob -- thank you both. I've found time to look deeper into this, and discovered (to my dismay) that these are pre-3.4 remnants. I had totally forgotten that we started looking at Koha in March 2011 (just before 3.4.0 the following month, with about 10,000 records from oOo via MarcEdit), migrated through 3.4, 3.6 to current 3.8. All these marc(xml) errors originate back in 2011 (some 3.2, some 3.4 according to items.datelastseen.)
The routines that take care of that are on C4::Biblio btw.
Yes -- I had looked at that (see my 2nd para below) -- the "redeeming" factor is that re-saving the *biblio* corrects the marc(xml) (editing items retains the error, adding items propagates the error.) I'm not sure if I can automate the corrections required (export/delete/re-import?) -- at worst, I'll have to set things up for our volunteers to open each biblio and re-save. Then I'll try to repeat the speed tests on 3.18 and see if this makes any difference. At the moment we've decided to stay with 3.08.24 because of the performance (our priorities as a non-lending library do not require all the other very positive improvements to 3.18) Again thanks and warmest regards -- Paul
El vie., 6 de marzo de 2015 0:10, Paul A <<mailto:paul.a@navalmarinearchive.com>paul.a@navalmarinearchive.com> escribió: Good morning|evening to you all. I'm looking for some help please for a problem [1] that has surfaced concerning "advanced search" (OPAC and staff) by "Shelving location" and by "Collection Code".
I can't find an bugs relating to this. <<http://perldoc.koha-community.org/C4/Biblio.html>http://perldoc.koha-community.org/C4/Biblio.html> states: When dealing with items, we must : /.../ 3. overwrite the MARC record (with the added item) into biblioitems.marc(xml)
but I can't easily find where or how marc(xml) gets *updated*... and I'm not even certain that this is not an "error" left over from 3.6 two years ago
I can do a certain amount directly in MySQL (painstaking UPDATE...SET...REPLACE), but additionally, we have many biblioitems.marc(xml) which do *not* contain 952$c or $8 data at all. Since upgrade to 3.8? if 3.6 didn't put them there, I have no idea how they got there ;={
Importantly, should 952$c and 952$8 even be present in biblioitems.marc(xml)? (The advanced search uses these apparently unedited data in preference to items.location and items.ccode)
Is there a routine/utility to do this?
[1] Most of our cataloging is done into "boxes" at 952$c level using a provisional 952$8 (CCODE); then a different volunteer does the final shelving, edits the 952$c and possibly modifies the CCODE -- e.g. a book from "box_rr198" gets put onto the "engineering" shelf rather than "navy". This is accurately reflected by all searches (I think) except by the advanced options "Shelving location" and "Collection" which appear to rely primarily on biblioitems.marc(xml) neither of which is being updated by saving the edit to "items" or in new items in 3.8
Many thanks -- Paul
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>