Hello
I found the size of file "tmp" is very high at
/var/lib/koha/library/biblios/tmp which is approx 83GB, saw there are a
lot of files generated there. I think by default there is no such files
after installation but I am not able to trace the reason for such files
which is much in number.
P
This is a temporary (given its name) directory used by Zebra. It looks
like you can remove it, but I have really no idea why it's so big.
Le lun. 5 oct. 2020 à 11:29, vinod mishra a écrit :
>
> Hello
>
> I found the size of file "tmp" is very high at
> /var/lib/koha/library/biblios/tmp which is
Hello
I have deleted all the files and now it started working again, but don't
know the cause of generating such huge files.
Thanks to all who helped and participated in the discussion.
With Regards,
Vinod Kumar Mishra,
Assistant Librarian,
Biju Patnaik Central Library (BPCL),
NIT Rourkela,
Sun
Hi John,
I looked in my db and noticed there was an entry "itemtypes" in the
table "authorised_value_categories". Do you also have this? I'm not sure
how item types as authorised values are managed since it is not a real
authorised value category.
Caroline
On 20-10-04 07 h 01, John Fawcett
Hi,
Maybe someone else on the list can contradict me, but I don't think that
is possible. Authority fields are only copied in matching biblio fields
(eg. in MARC 21, authority 100 fields are copied into biblio fields 100,
600, 700 or 800). Since 082 is outside those, it won't be copied.
If y
Hi Caroline
thanks for your answer. Yes I confirm that itemtypes is present in the
table "authorized_value_categories". This value has is_system = 1.
John
On 05/10/2020 15:47, Caroline Cyr-La-Rose wrote:
> Hi John,
>
> I looked in my db and noticed there was an entry "itemtypes" in the
> table "
It is possible that some junk characters in the data in one or many of
the fields which create a huge file. May be you can disable indexing
for a day or two in the crontab and see what happens. Regards,
Pandian br /> Quoting Jonathan Druart
:
This is a temporary (given its name) di
Hi
Can you please explain with example here ?
On Mon, 5 Oct 2020 20:44 , wrote:
> It is possible that some junk characters in the data in one or many of
> the fields which create a huge file. May be you can disable indexing
> for a day or two in the crontab and see what happens. Regards,
> P
thinking about this further the best solution might be to eliminate
field 995 r from the items menu altogether. It is probably redundant in
that 942 in the UNIMARC record already has this info. Not sure why an
item would need to be different.
John
On 05/10/2020 16:49, John Fawcett wrote:
> Hi Caro
Hi John,
the configuration alone should be enough. Some things to check maybe:
- if there are multiple frameworks installed, you will have to make the
change for all of them.
- if you have used SQL to change it, it might still cache the old value.
A restart (Plack, Memcached) helps here.
- Did y
Hi John,
if the item type from the item or from the record is used is determined
by the setting of the system preference item-level_itypes. Make sure the
setting fits your setup.
In a lot of libraries there might be branches using different item types
(you can also think of them as loan types, a
By default, the zebra indexing is being done every 30 seconds with all
the backup of indexed data including biblios etc. This may be disabed
at /etc/koha/cron.d where you have cron triggers for daily, hourly,
weekly. Location of these cron files may vary depends on your
installation. you
12 matches
Mail list logo
