Circulation Errors after Upgrade
Good afternoon, I recently installed a test server (a few months ago) for our church to migrate from Koha 3.01 to 3.6 (now at 3.8.03). As a part of the testing of the new server, our librarians finally took a look at the system and found some errors and I really have no clue where to start when it comes to troubleshooting them. 1. Trying to check-out, check-in or renewing items fails. The errors returned is "Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2965." 2. When searching our catalog, the list of results shows "No Holds Allowed" but on our current system holds are allowed. Librarians can place items on hold once they click into the item. 3. The list of search results also shows that there are "No items" under Location when we actually have many items. So far none of our items show anything being available. Can someone provide some tips or places to start when figuring out what is causing these issues? Thanks, Josh
Josh, I recently installed a test server (a few months ago) for our church to
migrate from Koha 3.01 to 3.6 (now at 3.8.03). As a part of the testing of the new server, our librarians finally took a look at the system and found some errors and I really have no clue where to start when it comes to troubleshooting them.
I suspect all the problems you report may stem from missing the remove_items_from_biblioitems.pl script. Did you run it? Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
I don't remember specifically running that script. Are there any parameters for it? Can you point me to where to look for it? Thanks, Josh On Mon, Jul 30, 2012 at 5:17 PM, Jared Camins-Esakov < jcamins@cpbibliography.com> wrote:
Josh,
I recently installed a test server (a few months ago) for our church to
migrate from Koha 3.01 to 3.6 (now at 3.8.03). As a part of the testing of the new server, our librarians finally took a look at the system and found some errors and I really have no clue where to start when it comes to troubleshooting them.
I suspect all the problems you report may stem from missing the remove_items_from_biblioitems.pl script. Did you run it?
Regards, Jared
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Josh, I don't remember specifically running that script. Are there any
parameters for it? Can you point me to where to look for it?
The file is misc/maintenance/remove_items_from_biblioitems.pl. If you run it with --help, it will give you instructions. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
I ran all of the upgrade scripts to get from 3.01. to 3.6. Based on the file, it looks like it should have run as a part of that process. When I try to run it to view the help it gives me a compilation error. Would it have logged somewhere if this failed as a part of the upgrade? Thanks, Josh On Mon, Jul 30, 2012 at 5:26 PM, Jared Camins-Esakov < jcamins@cpbibliography.com> wrote:
Josh,
I don't remember specifically running that script. Are there any
parameters for it? Can you point me to where to look for it?
The file is misc/maintenance/remove_items_from_biblioitems.pl. If you run it with --help, it will give you instructions.
Regards, Jared
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi Josh On 31 July 2012 12:36, Josh Mikow <joshmikow@gmail.com> wrote:
I ran all of the upgrade scripts to get from 3.01. to 3.6. Based on the file, it looks like it should have run as a part of that process.
Hmm which upgrade scripts are those?
When I try to run it to view the help it gives me a compilation error.
Whats the error? I bet its missing the path to the C4 modules
Would it have logged somewhere if this failed as a part of the upgrade?
No. It isnt run as part of the upgrade, because it only needs to be run in special circumstances, when coming from a pre 3.4.x version to a 3.6.x, and take a long time potentially.
From the INSTALL file in the UPGRADE section
"Koha 3.4.x or later no longer stores items in biblio records. If you are upgrading from an older version ou will need to do the following two steps, they can take a long time (several hours) to complete for large databases misc/maintenance/remove_items_from_biblioitems.pl --run misc/migration_tools/rebuild_zebra.pl -b -r " You need to run these as the user that runs rebuild_zebra normally (check your cron if you are unsure) and need to set the paths. For instance on my machine if I was using a package installed from the tarball sudo -u koha PERL5LIB=/usr/share/koha/lib KOHA_CONF=/etc/koha-conf.xml perl misc/maintenance/remove_items_from_biblioitems.pl --run If I installed from the packages (the best way) (but I think you used the tarball?) sudo koha-upgrade-to-3.4 instancename Chris
Hi Chris, When I imported our database into the 3.6.4 system at the time I ran the following: koha-upgrade-schema <instancename> then koha-uprade-to-3.4 <instancename> When I ran the 2nd command, the koha-upgrade-to-3.4 command kept returning a bunch of "Use of uninitialized value in pattern match (m//) at /usr/share/koha/lib/C4/Biblio.pm line 2953" . I asked and was told I could safely ignore those errors from the upgrade command. I actually install KOHA using the apt-get packages on Debian. I've used that to keep it up to date and apply patches as they come out. Do I need to try to re-run the upgrade to 3.4 or check any specific logs? Josh On Mon, Jul 30, 2012 at 5:55 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
Hi Josh
On 31 July 2012 12:36, Josh Mikow <joshmikow@gmail.com> wrote:
I ran all of the upgrade scripts to get from 3.01. to 3.6. Based on the file, it looks like it should have run as a part of that process.
Hmm which upgrade scripts are those?
When I try to run it to view the help it gives me a compilation error.
Whats the error? I bet its missing the path to the C4 modules
Would it have logged somewhere if this failed as a part of the upgrade?
No. It isnt run as part of the upgrade, because it only needs to be run in special circumstances, when coming from a pre 3.4.x version to a 3.6.x, and take a long time potentially.
From the INSTALL file in the UPGRADE section
"Koha 3.4.x or later no longer stores items in biblio records. If you are upgrading from an older version ou will need to do the following two steps, they can take a long time (several hours) to complete for large databases
misc/maintenance/remove_items_from_biblioitems.pl --run misc/migration_tools/rebuild_zebra.pl -b -r "
You need to run these as the user that runs rebuild_zebra normally (check your cron if you are unsure) and need to set the paths.
For instance on my machine if I was using a package installed from the tarball
sudo -u koha PERL5LIB=/usr/share/koha/lib KOHA_CONF=/etc/koha-conf.xml perl misc/maintenance/remove_items_from_biblioitems.pl --run
If I installed from the packages (the best way) (but I think you used the tarball?) sudo koha-upgrade-to-3.4 instancename
Chris
On 31 July 2012 16:59, Josh Mikow <joshmikow@gmail.com> wrote:
Hi Chris,
When I imported our database into the 3.6.4 system at the time I ran the following: koha-upgrade-schema <instancename> then koha-uprade-to-3.4 <instancename>
When I ran the 2nd command, the koha-upgrade-to-3.4 command kept returning a bunch of "Use of uninitialized value in pattern match (m//) at /usr/share/koha/lib/C4/Biblio.pm line 2953" . I asked and was told I could safely ignore those errors from the upgrade command.
I actually install KOHA using the apt-get packages on Debian. I've used that to keep it up to date and apply patches as they come out.
Cool, it is by far the easiest way to run Koha.
Do I need to try to re-run the upgrade to 3.4 or check any specific logs?
What you can do is in your report writer, write a report that does SELECT marcxml FROM biblioitems limit 5 That will get you 5 records, you can look at your marcxml and if it has 952 fields in it, the fields were not removed. Chris
Thanks Chris! Glad to know I'm doing this the best/recommended way. i'm refreshing my linux skills and also having to learn about library systems and it takes me a bit. For a limit of 5 records the file I downloaded with the query results was 183 lines so it looks like it may have run OK. here is an example of 1 row: "<?xml version=""1.0"" encoding=""UTF-8""?> <record xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:schemaLocation=""http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"" xmlns=""http://www.loc.gov/MARC21/slim""> <leader>00366nam a2200157Ia 4500</leader> <controlfield tag=""003"">OSt</controlfield> <controlfield tag=""005"">20120402152703.0</controlfield> <controlfield tag=""008"">080903s9999 xx 000 0 und d</controlfield> <datafield tag=""020"" ind1="" "" ind2="" ""> <subfield code=""a"">0020442009</subfield> </datafield> <datafield tag=""040"" ind1="" "" ind2="" ""> <subfield code=""c"">Bri</subfield> </datafield> <datafield tag=""100"" ind1="" "" ind2="" ""> <subfield code=""a"">Lewis, C. S.</subfield> </datafield> <datafield tag=""245"" ind1="" "" ind2="" ""> <subfield code=""a"">The Chronicles of Narnia: The Horse and His Boy</subfield> </datafield> <datafield tag=""650"" ind1="" "" ind2="" ""> <subfield code=""a"">Fantastic fiction.</subfield> </datafield> <datafield tag=""650"" ind1="" "" ind2="" ""> <subfield code=""a"">Fantasy.</subfield> </datafield> <datafield tag=""942"" ind1="" "" ind2="" ""> <subfield code=""c"">BOOK</subfield> </datafield> <datafield tag=""999"" ind1="" "" ind2="" ""> <subfield code=""c"">2</subfield> <subfield code=""d"">2</subfield> </datafield> </record> " Any other ideas on what to check? Josh On Mon, Jul 30, 2012 at 10:03 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
Hi Chris,
When I imported our database into the 3.6.4 system at the time I ran the following: koha-upgrade-schema <instancename> then koha-uprade-to-3.4 <instancename>
When I ran the 2nd command, the koha-upgrade-to-3.4 command kept returning a bunch of "Use of uninitialized value in pattern match (m//) at /usr/share/koha/lib/C4/Biblio.pm line 2953" . I asked and was told I could safely ignore those errors from the upgrade command.
I actually install KOHA using the apt-get packages on Debian. I've used
On 31 July 2012 16:59, Josh Mikow <joshmikow@gmail.com> wrote: that
to keep it up to date and apply patches as they come out.
Cool, it is by far the easiest way to run Koha.
Do I need to try to re-run the upgrade to 3.4 or check any specific logs?
What you can do is in your report writer, write a report that does
SELECT marcxml FROM biblioitems limit 5
That will get you 5 records, you can look at your marcxml and if it has 952 fields in it, the fields were not removed.
Chris
On 31 July 2012 17:13, Josh Mikow <joshmikow@gmail.com> wrote:
Thanks Chris! Glad to know I'm doing this the best/recommended way. i'm refreshing my linux skills and also having to learn about library systems and it takes me a bit.
Hmm that looks alright you could try a koha-rebuild-zebra -f to just see if that helps Chris
I tried running that but it didn't look like I did anything. If I go into a record for an item it shows available and in our library but when I search through the catalog under "Location" it shows "Availability: none" to the user and "No items" under the "Location" column for a librarian. I'm new to KOHA and libraries so any tips/help you can provide would help us make sure it works as it should. Is there a schedule task that I need to have run each day/hour/etc to make sure it is all indexed properly? Thanks, Josh On Tue, Jul 31, 2012 at 2:42 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
On 31 July 2012 17:13, Josh Mikow <joshmikow@gmail.com> wrote:
Thanks Chris! Glad to know I'm doing this the best/recommended way. i'm refreshing my linux skills and also having to learn about library systems and it takes me a bit.
Hmm that looks alright
you could try a koha-rebuild-zebra -f to just see if that helps
Chris
participants (3)
-
Chris Cormack -
Jared Camins-Esakov -
Josh Mikow