Paul A schreef op vr 14-11-2014 om 19:53 [-0500]:
> It's been running every minute for two years ;=} using
Under older versions, there was a chance of two zebra reindexes crashing
into each other, and I think that if this happened, it could be possible
that a change would get lost. Running every m
Paul's XSLT was using 001 for the id.
El sáb, nov 15, 2014 05:39 AM, Frédéric Demians
escribió:
> Paul, could you confirm that you use Zebra in DOM mode? It seems Zebra
> isn't
> configured properly, and so doesn't know where to pick up unique ID for
> biblio
> records (biblionumber field). With
Paul, could you confirm that you use Zebra in DOM mode? It seems Zebra isn't
configured properly, and so doesn't know where to pick up unique ID for biblio
records (biblionumber field). Without an ID to identify biblio records, Zebra
can't neither delete nor update a biblio record.
Check your Zebr
On 2014-11-15, at 1:53 PM, Paul A wrote:
> At 12:53 PM 11/15/2014 +1300, Mason James wrote:
>
>> On 2014-11-15, at 9:49 AM, Paul A wrote:
>>
>> > At 04:20 PM 11/14/2014 +, Tomas Cohen Arazi wrote:
>> >> Paul, I'm sorry you suffered that on your Koha, but I've never seen it.
>> >> I'm
>> >>
At 12:53 PM 11/15/2014 +1300, Mason James wrote:
On 2014-11-15, at 9:49 AM, Paul A wrote:
> At 04:20 PM 11/14/2014 +, Tomas Cohen Arazi wrote:
>> Paul, I'm sorry you suffered that on your Koha, but I've never seen
it. I'm
>> only aware of a situation that could trigger that on NORMARC (re
On 2014-11-15, at 9:49 AM, Paul A wrote:
> At 04:20 PM 11/14/2014 +, Tomas Cohen Arazi wrote:
>> Paul, I'm sorry you suffered that on your Koha, but I've never seen it. I'm
>> only aware of a situation that could trigger that on NORMARC (recently
>> fixed) using DOM indexing.
>> [snip]
>> > >
Greetings,
And what cronjobs do you currently have? Perhaps you don't even have your
partial reindex cronjob installed?
GPML,
Mark Tompsett
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/li
At 04:20 PM 11/14/2014 +, Tomas Cohen Arazi wrote:
Paul, I'm sorry you suffered that on your Koha, but I've never seen it. I'm
only aware of a situation that could trigger that on NORMARC (recently
fixed) using DOM indexing.
[snip]
> > > 3.8.5 (production) and from my test notes 3.12.various
Paul, I'm sorry you suffered that on your Koha, but I've never seen it. I'm
only aware of a situation that could trigger that on NORMARC (recently
fixed) using DOM indexing.
Otherwise, we've used 3.0, 3.8 and 3.12 without any similar behaviour.
El Fri Nov 14 2014 at 12:50:02, Tom Hanstra () esc
In my instance(s), I have few enough records that I just run a full
re-index daily. There have been a few times along the way where
incremental indexing might manage to miss a record. Doing a full index
regularly during the overnight hours just makes sure everything is in there.
Probably not nec
> 3.8.5 (production) and from my test notes 3.12.various and 3.14.2 required a
> complete biblio re-index after deleting a biblio record. Has this been
> fixed?
I don't think that was ever true.
-- Owen
--
Web Developer
Athens County Public Libraries
http://www.myacpl.org
__
At 01:42 PM 11/14/2014 +, Tomas Cohen Arazi wrote:
I see a couple situations when you could need a reindex:
- An upgrade explicitly states the need for it
- Changes on the index definitions
- Changing from GRS-1 to DOM indexing
- Weird/unexpected search results
3.8.5 (production) and from
I see a couple situations when you could need a reindex:
- An upgrade explicitly states the need for it
- Changes on the index definitions
- Changing from GRS-1 to DOM indexing
- Weird/unexpected search results
The latter means something is going wrong. In that situation, please report
back to us
Steven Nickerson schreef op do 13-11-2014 om 07:42 [-0500]:
> Aside from this rebuild, is there some other "complete" Zebra rebuild
> recommended, and if so on what frequency?
If you're seeing strange search results, in that they differ from what
the detail page says, then do a reindex.
Instructi
14 matches
Mail list logo
