Dear all, I already have the numbers of registered participants for
KohaCon2017 and I am happy to inform you that we had a total 188
participants during the last KohaCon both for the Main Conference and the
hackfest (we had people attending only the Main Conference and some only
attending the
Great! Thanks. & Thanks for the sql. Worked fine.
- Tim
On 6/27/2017 12:55 PM, Tomas Cohen Arazi wrote:
Tim, the authorised_values_branches table is not related.
The problem is that there are fields in your record(s) that are
expected to contain a branchcode. And they don't. That's
Luis, my first uncommented line on zebra-biblios-dom.cfg is
profilePath:/etc/koha/sites/:/etc/koha/zebradb/biblios/etc:/etc/koha/zebradb/etc:/etc/koha/zebradb/marc_defs/marc21/biblios:/etc/koha/zebradb/lang_defs/es:/etc/koha/zebradb/xsl
Compare it.
El mar., 27 jun. 2017 a las 15:21, Tomas
In your /etc/koha/sites//zebra-biblios-dom.cfg file, there should
be a reference to the 'lang_defs/es' dir on the path, first uncommented
line.
El mar., 27 jun. 2017 a las 15:18, Luis Moises Rojas (<
lmoisesro...@gmail.com>) escribió:
> Make sure you are using
Make sure you are using zebradb/lang_defs/es/sort-string-utf.chr: Well, i
change the file, but i do not know if i am using it. How do i know?
Did you choose spanish when creating the instance?: Yes.
On Tue, Jun 27, 2017 at 2:14 PM, Tomas Cohen Arazi
wrote:
> Make sure you
Make sure you are using zebradb/lang_defs/es/sort-string-utf.chr
Did you choose spanish when creating the instance?
El mar., 27 jun. 2017 a las 14:39, Luis Moises Rojas (<
lmoisesro...@gmail.com>) escribió:
> Hello everybody,
>
> We have:
> OpacdefaultSortField/OpacdefaultSortOrder set to: A-Z
Tim, the authorised_values_branches table is not related.
The problem is that there are fields in your record(s) that are expected to
contain a branchcode. And they don't. That's why Koha::Libraries->find() is
returning an undefined value (undef in Perl).
When you removed the FK constraint, you
Hello everybody,
We have:
OpacdefaultSortField/OpacdefaultSortOrder set to: A-Z (also we changed to
ascendet)
But when you enter in our OPAC (try it: www.catalogoenlinea.bijrd.gob.do),
and type letter, A and try to search: this is the result:
Ñam: el ñadu gloton...
Ícaro...
Églogan...
El entre
On 6/27/2017 9:08 AM, "D DuD>DtD2DtD1 D'D,D+D>D,DtN,DuD0DoN N
"@LightSys.org wrote:
Hi, Tim
It would be helpful to know if you upgraded using package or tarball.
[Николай Ластовка] I upgraded start command "do-upgrade-release", I have no
mind is it package or tarball, sorry!
Awesome. Thanks. I may be able to figure it out (I am pretty good at
poking and prodding, and finally figuring it out). I believe we only
have one branch, so I should be able to simply replace everything in the
sql to match the correct branch... (Yikes! Branchcode is used all over
the
Thank you for the pointers. We have a test site for just this sort of thing.
On Tue, Jun 27, 2017 at 1:49 AM, Tajoli Zeno wrote:
> Hi Elaine
>
> Il 26/06/2017 20:37, Elaine Bradtke ha scritto:
>
>> What's the best way to do this with Koha?
>> Would setting up a branch work,
You need to fix your data, so fields linked to branch codes actually
contain valid branchcodes. The band aid will work, but I think you need to
fix your data for good.
Koha got stricter regarding the data quality/completeness. This particular
case could be saved by some tweak like the one you
Hi, Tim
> It would be helpful to know if you upgraded using package or tarball.
[Николай Ластовка] I upgraded start command "do-upgrade-release", I have no
mind is it package or tarball, sorry!
>
> It also helps to know what *nix distro you are using (Centos, Ubuntu, etc)
>
[Николай
Previously, I noted that I was not able to reindex. I tracked it down
to the following.
My biblio_metadata file wasempty, and therefore my reindex could not
retrieve any biblio information.
Now that I know what to look for, there was this error during the upgrade:
[Thu Jun 22 22:29:11
Greetings,
It would be helpful to know if you upgraded using package or tarball.
It also helps to know what *nix distro you are using (Centos, Ubuntu, etc)
It looks like you may need to install a package?
You can usually see if the package is installed by running:
locate Cache/Memcached.pm
Hi Barton,
I've done some tests based on this page:
https://wiki.koha-community.org/wiki/Troubleshooting_Zebra
I will put the results here:
*yaz-client -c /etc/koha/zebradb/ccl.properties koha_test:9998/biblios*
/Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : 81
Name
Hello Katrin,
Thank you for your reply.
Upon my research I was/am also leaning towards a solution like that:
assigning the copy number with the homebranch prefix.
It'll still be needed to reprint labels for the delta items, but at least
Koha will allow for checkin/checkout.
Thanks,
Pedro Amorim
On Tue, Jun 27, 2017 at 5:17 AM, anjoze wrote:
> José
José,
Have you tried connecting via yaz-client? What about another z39.50 client?
It would be useful to know whether the encoding errors are in Koha or in
zebra.
--Barton
Hi there!
My name is Nikolay, I'm from Moscow, Russia, we use Koha LS. Last time ago koha
start working very slow. We did upgrade ubuntu server up to 12.04 and new
when we try connect to Koha we have next:
Software error:
Can't locate Cache/Memcached.pm in @INC (@INC contains:
Hi again.
From always (3.2 --> 16.11) I could not get the right encoding when
searching with Z3950 on other servers.
I've tried with all the available encodings (utf8, EUC-KR, ISO_5426,
ISO_6937, ISO_8859-1, MARC-8 ) but always have strange characters on
results.
I alway thought the problem was
Hi Elaine
Il 26/06/2017 20:37, Elaine Bradtke ha scritto:
What's the best way to do this with Koha?
Would setting up a branch work, or would it be better to set up a
different instance and somehow get them to link together for broader
searches?
if you setup a different instance you can't do
21 matches
Mail list logo