Zico, Lets take this to the general list, as MJ suggested. Shouldn't you be using the -z option for incremental updates? Nonetheless, that is not the cause of the problem. The problem does not occur in fresh installs, it seems to only occur where a data base has been upgraded from an earlier version. So does that suggest that a data element has been lost in the upgrade? If so, why is the problem only in the OPAC? It needs a bit of research to identify the exact circumstance. I won't be able to do that until after Christmas. Bob
________________________________________ From: koha-devel-boun...@lists.koha.org [mailto:koha-devel-boun...@lists.koha.org] On Behalf Of Zico Sent: Thursday, 17 December 2009 9:57 PM To: MJ Ray Cc: koha-devel@lists.koha.org Subject: Re: [Koha-devel] koha 3.0.4 biblio records On Thu, Dec 17, 2009 at 4:39 PM, MJ Ray <m...@phonecoop.coop> wrote: I'd try two things: 1. increase the debug level to 2 (or SetEnv KOHA_DEBUG 2 in the VirtualHost if that still works) to get a full backtrace and see what call results in a try to call clone on an undefined value; 2. check the databases for the record after each change and see what is happening with the edited and deleted records. Beyond that, a bit more description of how to reproduce the bug may be needed: for example, is it NoZebra? It`s not NoZebra. It`s Zebra. Which MARC type? MARC21 If it's zebra, how is the zebra being updated? (cronjob?) Yes, cronjob My crontab is: */1 * * * * KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -w >/dev/null -- Best, Zico No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.427 / Virus Database: 270.14.110/2568 - Release Date: 12/16/09 08:02:00 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
