s all of them or,
b) adding all of your biblionumbers in the relevant tab.
I hope this helps.
Kind regards,
Andreas Roussos
On Tue, 18 Feb 2020 at 09:04, Nalisha Tamang wrote:
> Dear all,
> We have imported 26,000 books from resourcemate into koha 19.05.04 but we
> have 082$a is fill
23, Nalisha Tamang wrote:
> Thank you for your suggestion... But there is one more thing I forgot to
> mention that when I see item 952$o it shows blank call number area blank
> but when i click edit item then 952$ o is filled. what have gone wrong
> with my data???
>
> O
and we print a few hundred labels per month at most -- this
printer can handle much more I reckon.
I hope this helps.
Kind regards,
Andreas Roussos
On Sat, 14 Mar 2020 at 10:33, Yatheesh lis wrote:
> Hi
>
> Can anyone suggest Thermal barcode printer suitable for small library
>
Hi Carlos,
I think that to match on character ranges you'll have to use RLIKE,
which is the regex-capable counterpart of the LIKE function.
Something like the following should work:
SELECT itemnumber, barcode, ccode, itemcallnumber, datelastseen
FROM items
WHERE location = "DISPLAY"
AND itemc
Hi Michael,
Has anyone ever seen this before? Can anyone maybe confirm this on his
own host with Debian 11 and Apache 2.4.51?
Yes, I've seen this before when I tried to set up a Koha 21.05
instance for testing purposes on a Debian 11 VM. I can confirm
it is still happening with Koha 21.11.00 o
Hi Michael,
I've tried to reproduce the issue you describe on a development
21.11.09 instance that I set up, but was not successful.
So, I have a few questions for you to help me diagnose this ;-)
Assuming a package installation, have you restarted the koha-common
service following the upgrade?
Hello again Michael,
Thank you very much for taking the time to provide these details!
I'm interested in finding what's causing this misbehaviour, so
please bear with me as I bombard you with more questions! ;-)
Have you made any staff interface customisations with JavaScript
or jQuery? Is ther
Good morning Hugo,
I came across the same issue a few months ago, and my research led me to
the following helpful mailing list post:
https://lists.katipo.co.nz/public/koha/2011-May/028899.html
In our case we were on version 21.11.04 and actually had to set both
min_spare_servers *and* min_se
Hi Fred,
The snippet you posted already has some "if" logic at the top, where it
checks for the presence of field 698.
You just need to wrap your tags within a similar conditional block.
Inside your for-each loop, try changing
name="href">/cgi-bin/koha/opac-search.pl?q=conference-name:"sele
Hello Aida,
We are UNIMARC users too (in Greece) and came across the same issue
while evaluating Koha 22.11.
You need to take a couple of steps in order for the MARC bibliographic
framework test to complete without errors.
However, I just wanted to point something out first: I can see fro
Hi Isabel,
If you're running Ubuntu, it looks like there's a workaround which
involves downgrading the libmysqlclient21 package.
For more information, please see here:
https://github.com/perl5-dbi/DBD-mysql/issues/354#issuecomment-1679677264
This issue has also been filed upstream with MySQ
. To avoid this we are misspelling
the new authority and correcting it afterwards. This of course is very
confusing and time consuming.
Any guidance would be very much appreciated.
Kind regards,
Andreas Roussos
Systems Administrator
Holy Monastery of the Paraclete
___
otate script.
Does anyone have any leads as to what may be causing this behaviour?
Thanks in advance!
Kind regards,
Andreas Roussos
Systems Administrator
Holy Monastery of the Paraclete
___
Koha mailing list http://koha-community.org
Koha@lists.kati
7814, it may be related and fix your
> problem.
> Let us know
>
> Regards,
> Jonathan
>
> On Tue, 25 Apr 2017 at 05:48 Andreas Roussos wrote:
>
> > Dear List,
> >
> > We are running Koha 16.05.02 on Debian 8, installed from packages.
> >
> > Recentl
in an earlier post by Francois Charbonnier (
https://lists.katipo.co.nz/public/koha/2014-October/041177.html), and
possibly remained unresolved.
Any guidance/assistance to what might be causing such behavior will be very
much appreciated.
Kind regards,
Andreas Roussos
Systems Administrator
H
Dear List,
We're running Koha 16.05.16 on Debian 8 with UNIMARC flavour.
We want to move to XSLT for the display of results and item
details in both OPAC and the Staff Client.
However, we noticed a few differences when using the default
stylesheets provided (UNIMARCslim2OPACDetail.xsl,
UNIMARCsli
ithub.com/a-roussos/php-koha/blob/master/koha_unused_authority_records.php
Hope this helps!
Kind regards,
Andreas Roussos
Systems Administrator
Holy Monastery of Paraklitos
On 28 November 2017 at 07:38, Eric Phetteplace wrote:
> Hi all,
>
> I'm wondering if anyone has a way to find authori
Hi Dimitris,
In your OPAC, if I choose 'Legal cases and case notes' in the Additional
content types for books/printed materials drop-down menu, I don't get any
results. From the "No results found!" page we can at least get the name
of the Zebra index that was queried ('ctype').
If you grep for "^
Not sure if it's the same issue, but have you tried the fix mentioned in
the following thread?
https://lists.katipo.co.nz/pipermail/koha/2017-December/049632.html
On 21 May 2018 at 22:37, camilabezerra wrote:
> Sorry, I didn't understand your question.
>
> I am using this report:
>
> SELECT b.b
Dear Caterina,
When you say "clean the indexes", do you mean finding _unused_ subject
authority records and removing them? If the answer is "yes", have a look at
the following thread:
https://lists.katipo.co.nz/pipermail/koha/2017-November/049404.html
On the other hand, if your intention is to co
Dear Caterina,
Try pasting the following SQL into a Koha report, it should give you the
number of occurrences per authority.
Please bear in mind that I made the following assumptions:
(a) your Topical Subject authorities go in UNIMARC field 606 of your biblios
(b) you have no more than 5 subjects
Hi Tom,
Have a look at the directive in
/etc/koha/sites//koha-conf.xml
The default value is "none,fatal,warn", but perhaps at some point it was
changed to something more verbose in your installation? (which would
explain the very large log files).
HTH,
Andreas
On 11 June 2018 at 16:24, Tom Hans
Hi All,
Apparently, 'gr' (for 'Greek') is still missing from the options to the
relevant configuration variable (ZEBRA_LANGUAGE) in
/etc/koha/koha-sites.conf.
This will particularly affect newcomers since they will be unaware that
such a language option for Zebra exists.
I have filed an enhanceme
Hi Michael,
There _may_ be a syntax error in your customised stylesheet.
What I tend to do whenever I make changes to our .xsl files is to test the
validity of the output by running the following in a terminal:
xsltproc
... and then I inspect the output. You can create a file with sample
MARC
Hi Admire,
Perhaps you've set the PERL5LIB environment variable, but not KOHA_CONF?
Or, you've set KOHA_CONF but it points to the wrong file?
Try running your script from within the shell set up by the command:
`koha-shell ` (for the list of INSTANCE_NAMEs run
`koha-list`)
as that will take ca
Hi Carlos,
Check out the following thread, you may find it informative:
https://lists.katipo.co.nz/pipermail/koha/2018-May/050593.html
If you need help constructing your query just reply here and I'll try to
help.
Kind regards,
Andreas
On Mon, 3 Dec 2018 at 02:54, Carlos Lopez wrote:
>
> Hi a
Hi there,
We use koha 3.02.02.00, and I've recently had to make a number of
corrections to our records using
SQL statements that basically did a search & replace in the 'marcxml' field
of the 'biblioitems' table.
An example of such a query is as follows:
UPDATE biblioitems SET marcxml = REPLACE(
Hello everyone,
We are running koha 3.20.4 in a development VM and have a problem when
making single character searches (i.e. searches that would normally return
a lot of results). Oddly enough, our production koha which is on v3.2.2
does not suffer from the same issue (please see the attached scr
Hello everyone,
We are running koha 3.22.00 in a development VM and have a problem when
making single character searches (i.e. searches that would normally return
a lot of results). Oddly enough, our production koha which is on 3.02.02
does not suffer from the same issue (please see the relevant s
Dear list,
We're running Koha 3.20.04 on Ubuntu 14.04, and recently enabled
ICU indexing as per the instructions on the wiki
(https://wiki.koha-community.org/wiki/Correcting_Search_of_Arabic_records)
Most searches work fine, but queries for certain Greek characters in OPAC
(for example "[χ.ό.]"),
Hi David,
Thank you for your reply. Please see my answers inline below:
On Tue, May 17, 2016 at 4:51 AM, David Cook
wrote:
> Hi Andreas,
>
> This problem looks a little familiar. I have a few questions.
>
> You find 335 records using yaz-client. Are you able to view those records
> using "show"
Hi David,
On Wed, May 18, 2016 at 4:46 AM, David Cook
wrote:
> Hi Andreas,
>
>
>
> Thanks for your response. It’s very helpful!
>
Thank _you_ for your time.
> As you say, the problem probably is in individual records in the results
> for "[χ.ό.]". Do you see the error in the OPAC immediately
Hi David, All,
Just wanted to say that someone I met at KohaCon'16 suggested an upgrade to
version 3.22.
I have just done that in a test VM and the problem is gone, i.e. searching
for "χ.ό." now works.
Cheers,
Andreas
On Mon, May 23, 2016 at 4:03 AM, David Cook
wrote:
> Hi Andreas,
>
>
>
> I j
Hello,
We plan to use authorities linking and hierarchy in production
to display thesaurus based topical subject authorities.
On a clean install of Koha 3.22 on Ubuntu using UNIMARC, we
created 1 biblio with 2 topical subject authorities (biblio
unimarc 607), the one being broader than the other
'View final record' link the resulting page does not show
the uploaded image and you have to manually refresh it for the cover image
to show.
Can anyone suggest any guidance?
Should we file a bug/enhancement request for this?
Kind regards,
Andreas Roussos
Systems Administra
Hi Igor, All,
The actual record exporting (in export_records.pl or via the Staff
Interface) is carried out by Koha::Exporter::Record::export(), which is
in fact capable of detecting warnings reported by Perl's MARC modules,
such as an invalid record length of more than 9 bytes when exporti
36 matches
Mail list logo
