Hello,
Go to Administration - Authorized values in the staff client.
For shelving location, modify LOC, for Collection code modify CCODE
Olugbenga Adara
Mobile: 234 (0) 8033220288
Home: 234 (2) 8721720
Skype: gbengaadara
Blog: http://gbengaadara.blogspot.com
Twitter: http://twitter.com/gb
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
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
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
>
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,
I am new to koha i want to implement the windows ver 2.2.9 which I have
done successfully (I hope so) since the "opac" is running well on the
network the "intranet" is not. please advice on what I should do i tried
googling unsuccessfully.
--
Dennis K. Njuguna
___
Salvete!
> I am new to koha i want to implement the windows ver 2.2.9 which I have
> done successfully (I hope so) since the "opac" is running well on the
> network the "intranet" is not. please advice on what I should do i
> tried
> googling unsuccessfully.
>
Welcome to the Community!
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
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
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
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
Greetings,
These are ideas being thought out loud, these are not directions. So please
don't blame me for anything, if something goes wrong.
If you are running under windows, you could look into installing VirtualBox
(www.virtualbox.org). I generally set it to use a Bridged Adapter, use a
wi
12 matches
Mail list logo
