d log back in.
Randy Rowe
Lincoln City Libraries I.T.
Original Message
From: "Paul"
Sent: 8/31/2012 3:40:10 PM
To: "Elaine Bradtke" , Koha@lists.katipo.co.nz
Subject: Re: [Koha] Zebra not updating biblios automatically in koha 3.8
At 08:37 PM 8/31/2012 +0100,
At 10:08 PM 9/3/2012 +0200, taj...@cilea.it wrote:
[snip]
In fact the value of 003 is always the same for all bib records of your
Koha instance.
My understanding is that it should not be _your_ library unless _you_
created the 001 control number. As I said earlier, there are other choices
and
On 2012-09-4, at 7:34 AM, Doug Kingston wrote:
> Biblio number is only relevant for bibs. What should be used for
> authorities?
fyi Doug,,,
all authority records have a unique auth_number value,
(thats used in the same way as a bib's biblionumber value)
> That is what I was referring to be
Hi to all,
> I would concur that 001 and 003 need to be taken together to have any
>> chance of a unique identifier. Our library has our own unique 003
>> (UkLoVW). For indexing, I suspect a better key to hand to zebra would be
>> the system control number (035 $a). Are these kept unique by koh
Doug,
Biblio number is only relevant for bibs. What should be used for
> authorities? That is what I was referring to below but the problem may be
> common to both objects.
>
> Authid is already stored in 001 in authority records. The problem that Ian
reports is relevant specifically and only to b
Biblio number is only relevant for bibs. What should be used for
authorities? That is what I was referring to below but the problem may be
common to both objects.
-Doug-
On Sep 3, 2012 9:49 AM, "Jared Camins-Esakov"
wrote:
> Doug,
>
> I would concur that 001 and 003 need to be taken together
Doug,
I would concur that 001 and 003 need to be taken together to have any
> chance of a unique identifier. Our library has our own unique 003
> (UkLoVW). For indexing, I suspect a better key to hand to zebra would be
> the system control number (035 $a). Are these kept unique by koha?
>
We a
I would concur that 001 and 003 need to be taken together to have any
chance of a unique identifier. Our library has our own unique 003
(UkLoVW). For indexing, I suspect a better key to hand to zebra would be
the system control number (035 $a). Are these kept unique by koha?
While I do believe
At 11:32 PM 9/1/2012 +0100, Ian Bays wrote:
Hi.
The 3.8 upgrade offers the dom indexing by default and if you have taken
that option (as seen in $KOHA_CONF) the xsl used instead of record.abs
(~/koha-dev/etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl)
uses a construct (z:id) f
Greetings,
I thought I'd interject a bit.
It would be good to build a tool to find duplicate control numbers.
I did this by exporting all the biblios, using:
marcprint (my python utility) | grep "=001" | sort | uniq -c | sort -r |
less
and looked for counts greater than 1.
I'll use your "m
Better yet, we could use 'uniq -d'. It only prints out the duplicate
lines, so the following should suffice:
marcprint | grep "=001" | sort | uniq -d
I agree we should also be able to do something with SQL or SQL/Perl pretty
easily, but this was quick.
-Doug
On 1 September 2012 17:26, Mark Tomp
Actually rebuild_zebra.pl -b -r -v does the trick. I had broken my
rebuild_zebra with some debugging logic while tracking down this problem.
zebraidx was not being called... We look good now on this issue.
Solution:
1. use 'checkNonIndexedBiblios.pl -c' to get a report of missing biblios.
2. vi
So doing some further research, it definitely looks like we have duplicate
control numbers (001). This is a data entry mistake and it looks like the
cataloger copied the biblios for similar entries. I have gone back and
altered the control numbers to be unique, but rebuild_zebra.pl -b -r is not
a
Hi.
The 3.8 upgrade offers the dom indexing by default and if you have taken
that option (as seen in $KOHA_CONF) the xsl used instead of record.abs
(~/koha-dev/etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl)
uses a construct (z:id) for the 001 which uses that (if it exists) as
On Sat, Sep 1, 2012 at 5:46 PM, Jared Camins-Esakov
wrote:
>
> Did you change your bibliographic frameworks? It could be a matter of the
> biblionumber not being stored properly.
jared,
No changes to the frameworks. Some of these records were created
quite some time ago. I couldn't swear to it,
On 1 September 2012 09:46, Jared Camins-Esakov
wrote:
> Doug,
>
> So environment variables are not the issue. We are carefully managing
>> those.
>>
>
> Make sure when you are using cron jobs that you set the environment
> variables IN YOUR CRONTAB. Setting environment variables elsewhere is a
>
Doug,
So environment variables are not the issue. We are carefully managing
> those.
>
Make sure when you are using cron jobs that you set the environment
variables IN YOUR CRONTAB. Setting environment variables elsewhere is a
recipe for confusion and misery down the road. However, this is -- as
So environment variables are not the issue. We are carefully managing
those.
I have tried using the new tool checkNonIndexedBiblios.pl (from patch 6566)
and it indeed finds a few recent biblios that are not indexed. Using the
-z option to mark them for indexing followed by a manual run of
rebuil
At 08:37 PM 8/31/2012 +0100, Elaine Bradtke wrote:
My colleagues are reporting a similar problem with 3.8.4
Downloading and editing of records seems to function normally, but
once it is saved, none of the usual searches brings it up, and
running a report on recently catalogued items give zero re
My colleagues are reporting a similar problem with 3.8.4
Downloading and editing of records seems to function normally, but
once it is saved, none of the usual searches brings it up, and
running a report on recently catalogued items give zero results.
mysql Ver 14.14 Distrib 5.1.63, for debian-li
20 matches
Mail list logo
