Re: [Koha] Framework Reports

2021-10-06 Thread Charles Kelley 
Hi again, Elaine!

In our latest exchange, on 7 Oct. 2021 at 02:00 [JST], you wrote:

We're on 21.05
> Elaine
> VWML 
>


Hmmm. This gives me pause and reconsider migrating to 21.05 instead of
20.05.

Maybe my bug was spotted earlier than I reported and fixed. Or it was
indirectly fixed when another bug was exterminated. If you have been
involved in software development, that does happen, as I'm sure many on
this list can attest. So that's what I hope as we begin the upgrade process.

In the meantime, my interim solution -- see other correspondence --
solves the problem for the moment.

Thanks for your help.

-- 

気を付けて。 /ki wo tukete/ = Take care.

-- Charles.

Charles Kelley, MLS
PSC 704 Box 1029
APO AP 96338

Charles Kelley
Tsukimino 1-Chome 5-2
Tsukimino Gaadenia #210
Yamato-shi, Kanagawa-ken
〒242-0002 JAPAN

+1-301-741-7122 [US cell]
+81-80-4356-2178 [JPN cell]

mnogoja...@aol.com [h]
cmkelley...@gmail.com [p]

linkedin.com/in/cmkelleymls 
Meeting Your Information Needs. Virtually.
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Reports timing out, prevents access to web interfaces

2021-10-06 Thread Bales (US), Tasha R 
Good afternoon,

I'm experiencing an issue where if I'm working in the staff interface and kick 
off a long-running Report, I'm unable to navigate to or use Koha in any other 
browser tab, or in any other browser, either in the staff or public interface.  
I've confirmed that this affects other users working on their own machines too; 
in other words, my report interrupts their access.

I doubt that this is intended behavior.  I'm going to try to do some 
query-tuning (any suggestions for tools to use to optimize/identify inefficient 
queries?).

Any other ideas to troubleshoot this issue?  I found an old list post that 
suggested the Koha Tuning 
Guide on the Koha Wiki, 
but it isn't entirely clear to me if it is comprehensive, or if all parts are 
relevant to our issue.  I'm hesitant to blindly start changing values.  Before 
we pursue the tuning, are there any other suggestions?  Is this really a 
problem that is expected to happen?

I should add that long queries that need to be run on a routine basis, we'd run 
via cronjob.  However, I'm worried that staff who work solely on the web might 
inadvertently run a big one-off report (or do a huge record load, also a 
problem), and bring down the whole system.

FWIW, we have two processors:  Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz.  We 
have about 1.3 million records and the same number of items.  We're using MySQL 
5.7, and Koha 20.11.06.

Regarding RAM, this is the output of the "free" command, if relevant:

totalused  freeshared   
 buff/cache   available
Mem:   65308616   203882041354324  10780021915472 
62437176
Swap:   8257532 7808256752


Tasha Bales
Enterprise Services
http://isesi.web.boeing.com/

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] stack number cannot be stored in Koha 21.05

2021-10-06 Thread Michael Kuhn 

Hi Katrin

> ah ok, that was a local change then?

Yes, it definitely seems so.

> Because it looks like it has always been tinyint:
>
> 
https://git.koha-community.org/Koha-community/Koha/src/branch/master/installer/data/mysql/kohastructure.sql#L3015 


>
> 
https://git.koha-community.org/Koha-community/Koha/src/branch/18.11.x/installer/data/mysql/kohastructure.sql#L932 


>
> 
https://git.koha-community.org/Koha-community/Koha/src/branch/3.2.x/installer/data/mysql/kohastructure.sql#L994 



Yes, I had checked that already.

> varchar should work on database side, I am not aware of a code side
> check, but there could be one.

Well, it doesn't... that's why I thought of a possible code side check...

> Anything helpful in the logs maybe?

No, unfortunately I couldn't find anything and I'm fed up doing further 
tests. My plan for now is to address the guy I suspect to be responsible 
for this (I didn't mention it but he even wrote a Perl script to 
automatically fill MARC 952$j with the next free number - including a 
letter).


> Maybe worth checking if deleteditems was altered as well.

"deleteditems" has datatype tinyint.

Many thanks again for your input!

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 m...@adminkuhn.ch · W www.adminkuhn.ch
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] stack number cannot be stored in Koha 21.05

2021-10-06 Thread Katrin Fischer 

Hi Michael,

ah ok, that was a local change then?

Because it looks like it has always been tinyint:

https://git.koha-community.org/Koha-community/Koha/src/branch/master/installer/data/mysql/kohastructure.sql#L3015

https://git.koha-community.org/Koha-community/Koha/src/branch/18.11.x/installer/data/mysql/kohastructure.sql#L932

https://git.koha-community.org/Koha-community/Koha/src/branch/3.2.x/installer/data/mysql/kohastructure.sql#L994

varchar should work on database side, I am not aware of a code side
check, but there could be one. Anything helpful in the logs maybe?

Maybe worth checking if deleteditems was altered as well.

Katrin

|
|


On 06.10.21 21:39, Michael Kuhn wrote:

Hi Katrin

> 952$j is mapped to items.stack by default that has the datatype
> tinyint(1) in the database. A common problem I have encountered here
> is that it won't save when you try to store something non-numeric or
> outside the range of tinyint. Could that be the issue?

Yes, this would indeed be a problem... Thank you very much for the hint!

Our library was working with Koha 18.11 before - where it was possible
to store content like "m011577".

Looking into http://schema.koha-community.org/18_11/tables/items.html
shows that in this version the datatype was BIT(0) which seems to mean
mean "tinyint". In my Koha 21.05 demo installation I see it actually
is "tinyint".

However when asking the actual Koha 21.05 library database the
datatype is given as "varchar"!

So it seems like someone has unscrupulously changed the datatype of
this field in the past (a very bad idea). But then again - shouldn't
the database accept value "m011577" when the datatype is "varchar"? At
least in Koha 18.11 it seems to have worked.

I was able to successfuilly insert "011577". But not "m011577". Is
there maybe a script that checks if the values are of the correct
datatype when trying to store anything in the database? Maybe the guy
responsible for this problem also changed the datatype in such a script?

Best wishes: Michael

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] stack number cannot be stored in Koha 21.05

2021-10-06 Thread Michael Kuhn 

Hi Katrin

> 952$j is mapped to items.stack by default that has the datatype
> tinyint(1) in the database. A common problem I have encountered here
> is that it won't save when you try to store something non-numeric or
> outside the range of tinyint. Could that be the issue?

Yes, this would indeed be a problem... Thank you very much for the hint!

Our library was working with Koha 18.11 before - where it was possible 
to store content like "m011577".


Looking into http://schema.koha-community.org/18_11/tables/items.html 
shows that in this version the datatype was BIT(0) which seems to mean 
mean "tinyint". In my Koha 21.05 demo installation I see it actually is 
"tinyint".


However when asking the actual Koha 21.05 library database the datatype 
is given as "varchar"!


So it seems like someone has unscrupulously changed the datatype of this 
field in the past (a very bad idea). But then again - shouldn't the 
database accept value "m011577" when the datatype is "varchar"? At least 
in Koha 18.11 it seems to have worked.


I was able to successfuilly insert "011577". But not "m011577". Is there 
maybe a script that checks if the values are of the correct datatype 
when trying to store anything in the database? Maybe the guy responsible 
for this problem also changed the datatype in such a script?


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 m...@adminkuhn.ch · W www.adminkuhn.ch
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Next Cataloging SIG!

2021-10-06 Thread Hernandez, Heather H 
Hi, all!

The next Koha-US Cataloging Special Interest Group ("Cat SIG") meeting is this 
Thursday, October 7, 2021, at 8 PT, 9 MT, 10 CT, 11 ET, and you don't have to 
be a member of Koha-US to join us!  You don't even need to self-identify as a 
cataloger!  Join us for our usual roundtable of questions, solutions and 
resource brainstorming, tips, tricks, suggestions, bug & development awareness, 
and the usual laughter, fun, and fellowship to discuss anything cataloging, 
authority, or metadata related in Koha.  Actual catalogers do attend, as well 
as the cataloging curious and those who have had cataloging thrust upon them!

Information on joining us is on the Koha-US calendar:
https://koha-us.org/event/cataloging-special-interest-group-2/?instance_id=6292

Can't make it?  No worries--it will be recorded and available on the Koha-US 
YouTube Channel:
https://www.youtube.com/c/kohaUS/playlists
(See the Cataloging Special Interest Group's playlist for more cataloging fun!)

As ever, feel free to send me any questions or topics for discussion ahead of 
time!  See you there!
--h2
~~~

Ms. Heather Hernandez (she, her, hers)
Technical Services Librarian
San Francisco Maritime National Historical Park Research Center
2 Marina Blvd., Bldg. E, 3rd floor, San Francisco, CA  94123-1284
415-561-7032, 
heather_hernan...@nps.gov
Library catalog: http://keys.bywatersolutions.com/
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] stack number cannot be stored in Koha 21.05

2021-10-06 Thread Katrin Fischer 

Hi Michael,

952$j is mapped to items.stack by default that has the datatype
tinyint(1) in the database. A common problem I have encountered here is
that it won't save when you try to store something non-numeric or
outside the range of tinyint. Could that be the issue?

Katrin

On 06.10.21 20:47, Michael Kuhn wrote:

Hi

In our library we use Koha 21.05.02 on Debian GNU/Linux 11.

As we found out it not possible to store the content of field 952$j
(stack / shelving control number) in the Koha database. I have also
tested this on my demo installation with Koha 21.05.00 and on another
demo installation with Koha 21.05.04 - everywhere the same.

Can anyone please confirm this? If yes, I will open a bug report.

Best wishes: Michael

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] stack number cannot be stored in Koha 21.05

2021-10-06 Thread Michael Kuhn 

Hi

In our library we use Koha 21.05.02 on Debian GNU/Linux 11.

As we found out it not possible to store the content of field 952$j 
(stack / shelving control number) in the Koha database. I have also 
tested this on my demo installation with Koha 21.05.00 and on another 
demo installation with Koha 21.05.04 - everywhere the same.


Can anyone please confirm this? If yes, I will open a bug report.

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 m...@adminkuhn.ch · W www.adminkuhn.ch
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Framework Reports

2021-10-06 Thread Elaine Bradtke 
We're on 21.05
Elaine
VWML 



On Tue, Oct 5, 2021 at 6:31 PM Charles Kelley  wrote:

> Hello, Elaine, et al!
>
> In our latest exchange, on 6 Oct. 2021 at 05:50 [JST], I received the
> following through the Koha Discussion Group:
>
> Thank you for your reply.
>
> ODS worked for me, I haven't tried the other two.  Which version of Koha
>> are you using?
>> Elaine
>> VWML 
>>
>
> Koha 20.05. We will begin migrating to 20.11 in a month or so, first
> on the development machine, then on the production machine.
>
> --
>
> 気を付けて。 /ki wo tukete/ = Take care.
>
> -- Charles.
>
> Charles Kelley, MLS
> PSC 704 Box 1029
> APO AP 96338
>
> Charles Kelley
> Tsukimino 1-Chome 5-2
> Tsukimino Gaadenia #210
> Yamato-shi, Kanagawa-ken
> 〒242-0002 JAPAN
>
> +1-301-741-7122 [US cell]
> +81-80-4356-2178 [JPN cell]
>
> mnogoja...@aol.com [h]
> cmkelley...@gmail.com [p]
>
> linkedin.com/in/cmkelleymls 
> Meeting Your Information Needs. Virtually.
>
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Excluding fields from the OPAC search

2021-10-06 Thread Katrin Fischer 

Hi,

unfortunately the problem is a bit more complicated. :(

I think since our switch from grs-1 to dom indexing, the kw index
includes the whole record, where before that switch it was 'everything
that is indexed'. So changing the configuration of individual
fields/indexes won't make a difference. See:

*Bug 15050*
 -
Nonpublic note searchable from OPAC

I am not sure if this is solved already with Elasticsearch.

Some things you could do to avoid issues is linking 952$e to a vendor
record using the id. I've been thinking it would be nice if we had a
value builder to do this for a while. If you add items from acquisition
it will also fill source of acquisition with the id, so that would make
things more consistent.

For internal notes I think a good rule of thumb would be to avoid using
personal names whenever possible. For some use cases internally agreed
on codes or the cardnumber might work. Having a separate feature for
adding notes that don't end up in the MARC records (and possible
exports, OAI etc.) might be a good idea anyway.

Hope this helps

Katrin

On 06.10.21 13:04, Owen Leonard wrote:

(e. g.
MARC 952$e the source of acquisition, or MARC 952$x the non-public note)

If these are indexed by default I think that should be considered a bug.

  -- Owen


___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Excluding fields from the OPAC search

2021-10-06 Thread Owen Leonard 
> (e. g.
> MARC 952$e the source of acquisition, or MARC 952$x the non-public note)

If these are indexed by default I think that should be considered a bug.

 -- Owen

-- 
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Excluding fields from the OPAC search

2021-10-06 Thread Michael Kuhn 

Hi

In our library we use Koha 18.11.01 with Debian GNU/Linux 9.

Is it possible to switch off fields in the OPAC for the keyword search 
or for the search in general so that they cannot be searched? (e. g. 
MARC 952$e the source of acquisition, or MARC 952$x the non-public note)


How do other libraries deal with the fact that, for example, the source 
of acquisition unnecessarily inflates the search result?


Best wishes: Michael Kuhn
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha