On 2014-11-15, at 9:49 AM, Paul A wrote: > At 04:20 PM 11/14/2014 +0000, 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 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. [snip] > > It is true on our production box (and its backup; sandbox in other use) Koha: > 3.08.05.000 on Linux 3.2.0-31-generic (12.04LTS), Perl version: 5.014002, > MySQL version: mysql 5.5.24, > Apache version: 2.2.22, Zebra: 2.0.44 > > Pls see > <http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=kent+beyond+reef>, > two biblios for Kent, "Beyond the reef": one is good, the other has been > deleted, gives a 404 on the OPAC page, but will not go away from Zebra by > cron job alone (it will go away next time I CLI re-index.) I have a feeling > that when zebra says "incremental" it means just that -- adding new data, but > not deleting what has gone from MySQL. > > Slightly different case, > <http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=steele+worcester> > -- this was produced by "overwriting" an existing biblio (old, incomplete) > with a new Z39.50, and adding an item -- it's the same biblio, but the "dead" > instance will not disappear until I re-index. >
> This is a further example of the (for us) need to CLI re-index as the cronjob > does not handle it. you should show an example of your cron file - its probably just misconfigured? _______________________________________________ Koha mailing list http://koha-community.org [email protected] http://lists.katipo.co.nz/mailman/listinfo/koha
