- Koha - lists.katipo.co.nz

MARC frameworks in Koha
by Marcel de Rooy 07 Aug '17

07 Aug '17

Hi developers or librarians, If you are interested in say sorting search results or lists by publication date based on 260 and RDA 264, please read further. OR If you use varying kohafield mappings across your MARC frameworks. Say you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in framework B. Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306) is aimed to resolve the issue of having the copyrightdate in two MARC fields. It allows you to have multiple mappings per kohafield. So you can connect 260c and 264c to copyrightdate. Current Koha allowed you to add the second mapping already in the frameworks, but it silently ignores one of the two. In finishing this development however, I got stuck at the following question: Should Koha really allow varying kohafield mappings per framework? In the above example the multiple mappings feature should resolve the need of having a different assignment for copyrightdate between framework A and B. Both could simply have two mappings for copyrightdate. Although Koha more or less allows you to add kohafield assignments per framework via the MARC frameworks, it does not really support kohafields per framework. (The Koha to MARC mappings tool in Administration does change the mappings in Default and copies them to other frameworks.) We have GetMarcFromKohaField calls in the codebase that do not pass a framework code. And when we process search results or import records, we do not have a framework code either. So in those cases Koha just uses the kohafield mappings from the Default framework, although you might have specified another mapping in the associated framework of a search result. I would propose now to make the decision that we only use one set of kohafield mappings (those from Default), and that we do no longer allow changes to kohafield mappings in the other frameworks. The possibility of adding multiple mappings per kohafield hopefully removes most objections to that approach as illustrated in the frameworks A and B example. I submitted my changes so far on the Bugzilla report. If we agree on Default as the authoritative framework for these mappings, I will still add code to change GetMarcFromKohaField calls etc. If you have stringent reasons for maintaining varying kohafield mappings per framework and your need for them cannot be resolved with multiple mappings, please respond and provide information about the fields you are mapping differently across your frameworks. Any other feedback is welcome too. Thanks, Marcel

1 0

Please Help Me
by Rajesh Shelar 07 Aug '17

07 Aug '17

Dear All Friends, i request Please anybody facing the NAAC-2016-17 ,so i request please send me the NAAC submit ion Report & Point. -- ***Thanks & Regards* *Mr. Rajesh R.Shelar* *Sadhu Vaswani Institute Of Management Studies For Girl's ( MBA )* *Koregaon Road,Pune* *Mob.No.8380941380* *Save Water......Conserve Life.............*

1 0

Retirement Village Library
by Eleanor Bensemann 04 Aug '17

04 Aug '17

Hi everyone. I have been a librarian most of my life, and am still working in a casual on-call capacity. I have recently taken over the management of this small library and am running it with a team of helpers. There is a catalogue system of sorts on Excel sheets but it is far from user friendly. I am wondering if Koha would be a good option. This would just be a catalogue; the borrowing is strictly based on honesty with people writing their issues on a card, and crossing off when they return. Any advice appreciated. Thanks, Eleanor

4 3

Slow OPAC search
by Manoj Kummini 03 Aug '17

03 Aug '17

Hello everyone, I am new on this list, and have just begun, with a colleague, managing the KOHA installation in our library that has about 10000 books and some journals. Our OPAC had become terribly slow and on exploring we noticed that a mysqldump would result in a file of over 5GB. This large size, we realized, was due to the cleanup_database.pl script not being called. After running it for about a week with --sessdays 7 --zebraqueue --list-invites --mail --merged --import --logs --searchhistory --restrictions we have brought the mysqldump file to about 20-22 MB. While the speed of an OPAC search has improved considerably, it is still slow. For example, as suggested by a reply to a similar question, I looked at "Inspect Element > Network" and found that most queries of GET opac-detail.pl and opac-search.pl take about 9-10 seconds. Koha Version: 3.2202000 (<meta name="generator" content="Koha 3.2202000" />) running on a virtual machine (Debian 8.3). The base machine is Debian 9.0. MySQL server 5.5.47-0+deb8u1 is on the VM itself. Uses zebra. On the virtual machine # free -m gives total used free shared buffers cached Mem: 16023 2042 13981 341 174 1290 -/+ buffers/cache: 576 15446 Swap: 16383 0 16383 We plan to upgrade to Koha 17.05 soon, but wanted to understand how to speed up the search. Is moving to a stand-alone server the only solution? I am new to this, so I might not have given you all the relevant information about the problem. Please let me know if some other piece of information will help. Thank you. With regards, Manoj. -- Manoj Kummini Associate Professor, Mathematics, Chennai Mathematical Institute, Siruseri Tamilnadu 603103. India. 12 deg 50 min N, 80 deg 13 min E. http://www.cmi.ac.in/~mkummini/index.html

2 3

Report error (SQL )
by Luis Moises Rojas 03 Aug '17

03 Aug '17

Hello everybody. We have an sql senteces to extract SUBTITLE (ExtractValue(biblioitems.marcxml, '//datafield[@tag="245"]/subfield[@code="b"]') AS "Subtitulo) but now it say this field is obsolete. Where is the subttile? Thanks -- *Luis Moisés Rojas P.* <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Libre de virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 3

Having sevaral errors
by Luis Moises Rojas 03 Aug '17

03 Aug '17

Hello everybody, We are having many error: 1. When in catalogin when you search a title and click the TITLE to edit, it say: Export bib-23322.dublin...xml and Says: MARK VIEW and nothing happen 2. In report , option USE SAVE REPORT (utilizar salvados), say: UPDATING SQL. Why? 3. When try to edit a patron, we got this error (even if the patron is new o to edit) Template process failed: undef error - DBIx::Class::Storage::DBI::_dbh_execute(): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'koha_library.me.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at /usr/share/koha/lib/Koha/Objects.pm line 120 Any help? Thanks -- *Luis Moisés Rojas P.* <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Libre de virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

How to remove unwanted characters when importing MARC data?
by Michael Kuhn 03 Aug '17

03 Aug '17

Hi Our library receives MARC data from EKZ (a German cataloging data provider) which includes two unwanted characters: * a beginning "non-sorting character" * an ending "non-sorting character" These characters can't be seen in the OPAC and in the hitlist of the staff client, but they do appear in the framework and also in the top line of the webbrowser. Here is an example of a file containing such characters: http://adminkuhn.ch/download/kuhn0000000 When opening the original .mrc file with vi these characters show as: <98>The<9c> obsession With "od -c" they show as: 302 230 T h e 302 234 o b s e s s i o n Of course these characters could be removed e. g. with sed (but this will result in a wrong character length in MARC LEADER positions 0-4) and also it has to be done separately on the shell outside and before the regular importing process. Or even using software like MarcEdit. Now the question is if there is an EASY way how to delete these unwanted characters within Koha, for example by using the MARC modification templates which is used anyway when loading such data? Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik(a)adminkuhn.ch · W www.adminkuhn.ch

5 10

Koha capacity planning advice?
by Chris Brown 03 Aug '17

03 Aug '17

Gentle Reader, We are considering using Koha amongst a group of volunteer-run libraries here in Sheffield (UK). We'd probably host it on a machine "in the cloud" and I am looking for advice on how much capacity we need to plan for (CPU power, RAM, disk space etc). As a very rough guide, we might need to support up to six libraries each with around 4,000 books and 1,000 users. It is hard to estimate transaction rates but I wouldn't anticipate we would ever exceed 20 checkout/checkin operations per minute (aggregated over all the libraries) and the average would be much less. Any advice would be appreciated. In particular if anyone is hosting Koha using Amazon Web Services, which machine type are you using? Thanks and Best Regards, Chris Brown (Volunteer at Greenhill Library, Sheffield)

2 1

Re: [Koha] [Important] Update your MySQL|MariaDB configuration to avoid data loss
by Jonathan Druart 03 Aug '17

03 Aug '17

Vinod, Yes you should create the file to make sure the situation will not appear again for other rows. For the corrupted records (the ones returned by the SQL queries), please follow bug 19016. Regards, Jonathan On Thu, 3 Aug 2017 at 05:00 vinod mishra <mishravk79(a)gmail.com> wrote: > Dear All, > > I am using Koha 16.11.07 and because of below problems i faced lot of > transaction related issues, since it was start of the koha so i simply > deleted all circulation history (Very less which came along with test > database during setup) and now things work fine. I did not upgraded koha > too and using RFID which is configured via Koha SIP. Everything is working > fine now but as per the instruction i run commands and found some output > while excecuted below three so please suggest. Please suggest should i > create the file as suggested in the chain of email? or leave it as it is. > > > SELECT r.reserve_id FROM reserves r JOIN old_reserves o ON r.reserve_id=o.reserve_id; > > SELECT b.biblionumber FROM biblio b JOIN deletedbiblio db ON b.biblionumber=db.biblionumber; > > SELECT i.itemnumber FROM items i JOIN deleteditems di ON i.itemnumber=di.itemnumber; > > > > With Regards, > > Vinod Kumar Mishra, > Assistant Librarian, > Biju Patnaik Central Library (BPCL), > NIT Rourkela, > Sundergadh-769008, > Odisha, > India. > Mob:91+9439420860 > Website: http://mishravk.com/ > ORCID ID: http://orcid.org/0000-0003-4666-7874 > > *"Spiritual relationship is far more precious than physical. Physical > relationship divorced from spiritual is body without soul" -- Mahatma > Gandhi* > > On Wed, Aug 2, 2017 at 3:15 PM, Jon Knight <J.P.Knight(a)lboro.ac.uk> wrote: > >> On Tue, 1 Aug 2017, Bortel, Gary wrote: >> >>> For a multi-tenant installation with multiple MySQL databases... >>> >>> "The Solution" ( >>> https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix) >>> recommends adding "init-file=/var/lib/mysql/init-file_kohadev.sql" in the >>> my.cnf MySQL configuration file, then creating the appropriately configured >>> "init-file_kohadev.sql" file. Where there are multiple Koha databases, >>> should one add multiple "init-file=..." statements to my.cnf as well as >>> multiple init-file_kohadev.sql files? Or will MySQL only accept one >>> init-file directive in which case the .sql file would include multiple >>> blocks of code...one for each database? >>> >> >> I'd say that its up to you really - both will work. If you use just one >> "init-file_kohadev.sql" file you'll just have to repeat all the SQL, just >> changing the database in the "use" line. If you've got lots of Koha >> instances that file is going to be quite long. >> >> Personally for tidiness and ease of maintenance I'd probably opt for one >> init file per Koha database, as those would be clearer and could then be >> maintained more easily using normal Linux command line tools and a few Perl >> scripts. I assume people hosting lots of tenants are probably using tools >> like Ansible to set up provisioning of a new Koha instance so these files >> would be created from a template and just one line added/removed from the >> my.conf file. >> >> Jon >> >> _______________________________________________ >> Koha mailing list http://koha-community.org >> Koha(a)lists.katipo.co.nz >> https://lists.katipo.co.nz/mailman/listinfo/koha >> > >

1 0

Koha Acquisition Module - problems when modifying the price, conversion rate and currency while receving the order
by Paul Pandian 03 Aug '17

03 Aug '17

Hi, We at The Institute of Mathematical Sciences, Chennai, India have been successfully been using all the modules of Koha including serials module. We have recently upgraded to the version 16.11.05 from 3.22 without any issues. We request Koha developers to kindly look at the following issues with regard to Acquisition module: 1. Koha->Acquisitions->Vendor->Receive shipment 2. Invoice details are filled in -> Next 3. Under receipt summary, select the basket and receive the item If no changes are required like price, currency and conversion rates etc, then no problem and finish the receiving. But, when we need to change the price or currency or conversion rates, then option available to effect the change is only through editing the orderline number (by clicking the orderline number) in the receipt summary page. In Koha 3.22: While editing the order line number, the URL passes two parameters viz.1. ordernumber and 2.booksellerid as shown below: http://library.imsc.res.in:8001/cgi-bin/koha/acqui/neworderempty.pl?ordernu… As you may notice, the parameters passed in the URL hold good for books acquisition. But for the serials, subscriptionid is another important parameter to be passed in the URL to identify the particular serial subscription. This is not provided in Version 3.22. We manually pass this subscriptionid parameter in the URL as below to acheive the functionality: http://10.96.68.205:8001/cgi-bin/koha/acqui/neworderempty.pl?ordernumber=4&… In Koha 16.11.05 In 16.11.05, the subscriptionid as a parameter is also being passed alongwith ordernumber, booksellerid in the URL while editing the orderline for change of price, currency and conversion rate when receiving the item as follows: For Serials: http://10.96.68.172:8001/cgi-bin/koha/acqui/neworderempty.pl?ordernumber=79… This works without any problem (It is being fixed in the 16.11.05 which was a bug in 3.22) For Books: http://10.96.68.172:8001/cgi-bin/koha/acqui/neworderempty.pl?ordernumber=79… As you may notice in the above URL, there is no subscriptionid value as it is a book, hence the following error occured: Software error: Cannot insert order: Mandatory parameter basketno is missing at /usr/share/koha/intranet/cgi-bin/acqui/addorder.pl line 289. We have to manually remove the parameter &subscriptionid=, then only are we able to process the invoice and receive the book. THIS IS A BUG. Many of you who use acquistion for both books and Serials must have come across the above problems and request the Koha Developers community to kindly spare some to fix these problems at the earliest. Looking forward to your help! Thanks and Regards, Paul Pandian and Maruthu Pandiyan Institute of Mathematical Sciences CIT Campus, Taramani Chennai 600113, India

2 3