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 propose. It is maybe worth filling a bug, because the previous behaviour worked more gracefuly. El mar., 27 jun. 2017 a las 10:25, Tim Young (<Tim.Young@lightsys.org>) escribió:
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 2017] updatedatabase.pl: DBD::mysql::db do failed: *Cannot add or update a child row: a foreign key constraint fails* (`kohadb2015`.`biblio_metadata`, CONSTRAINT `biblio_metadata_fk_1` FOREIGN KEY (`biblionumber`) REFERENCES `biblio` (`biblionumber`) ON DELETE CASCADE ON UPDATE CASCADE) [for Statement " [Thu Jun 22 22:29:11 2017] updatedatabase.pl: INSERT INTO biblio_metadata ( biblionumber, format, marcflavour, metadata ) SELECT biblionumber, 'marcxml', 'CHANGEME', marcxml FROM biblioitems;
I think this is where the upgrade failed; the newly created biblio_metadata has a foreign key:
*CONSTRAINT `biblio_metadata_fk_1` FOREIGN KEY (biblionumber) REFERENCES biblio (biblionumber) ON DELETE CASCADE ON UPDATE CASCADE*
When doing the bulk migration, we probably need to turn off foreign key checks before doing the update:
SET FOREIGN_KEY_CHECKS=0;
And then put them back once it has been done:
SET FOREIGN_KEY_CHECKS=1;
[update having solved the problem] This glitch was caused primarily by a few different things: 1) a previous update to the mysql did not upgrade all the users. The debian-sys-maint user was somewhat broken. Various things that depended on this user failed during the upgrade. 2) We have some broken data in our install. At one time we had a number of records get corrupted, which resulted in records that do not have the records corresponding to their foreign keys. 3) I did not immediately notice the importance of the error logs (above) telling me that my data had not been copied over.
To fix my mysql issues with debian-sys-maint, I ended up running
# mysql_upgrade --force -uroot -p
This repaired the mysql users table.
Being a wise sysadmin, I had a backup database [kohadb2015] which had our original data. To populate that table with the marc data, I ran the following sql:
SET FOREIGN_KEY_CHECKS=0;
INSERT INTO koha_opac.biblio_metadata ( biblionumber, format, marcflavour, metadata ) SELECT biblionumber, 'marcxml', 'CHANGEME', marcxml FROM kohadb2015.biblioitems;
UPDATE biblio_metadata SET marcflavour = (SELECT value FROM systempreferences WHERE variable="marcflavour");
SET FOREIGN_KEY_CHECKS=1;
After that, I was able to reindex fine.
When the reindex was complete, the pages would still not load. I was getting an error rendering the page. Can't call method "branchname" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 1627
I am not entirely sure if this is yet another problem with my data, or if I have some odd setting somewhere. What I did, however, was to modify the koha code to avoid it blowing up:
vi /usr/share/koha/lib/C4/Biblio.pm +1627
if ( $tagslib->{$tag}->{$subfield}->{'authorised_value'} eq "branches" ) { *if(defined(Koha::Libraries->find($value)))* { return Koha::Libraries->find($value)->branchname; }
- Tim Young
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F