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:pau...@navalmarinearchive.com>pau...@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>
_______________________________________________
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/
