Koha 2.0.0 to 2.2.9 migration - catalogue search doesn't find anything
Hello to the list, With some help from Chris and the rest of the team that was at Katipo earlier this year, I did a migration of an existing Koha 2.0.0 install over to Koha 2.2.7. (Thanks for #koha on IRC!) At that stage, the database was upgraded to 2.2.7 using the koha.upgrade script. But the catalogue search did not return any results. Further investigation showed that we needed to run one more script: koha2marc.pl Finally we had a working Koha 2.2.7 system. I have since moved everything to our dedicated server and re-installed everything from scratch using Koha 2.2.8. For the database upgrade, I saved a MySQL dump, then imported that onto the 2.2.8 system. This is where things continue to fail. The catalogue search once again does not work. So I tried the koha.upgrade script once again, to no avail. Today we decided to upgrade to Koha 2.2.9 to fix the outstanding bugs. After upgrading the database, the catalogue search still does not work. Every search on the OPAC quick search page returns the same result: one record, prolly the first in the biblio section of the database. The tables are populated with records, as one would expect, e.g. here are some sample row counts: Table biblio: 16473 rows Table biblio_framework: 0 rows Table biblioanalysis: 0 rows Table biblioitems: 16324 rows Table bibliosubject: 15820 rows Table bibliosubtitle: 3902 rows Table bibliothesaurus: 0 rows Table branches: 10 rows Table items: 16448 rows Table marc_biblio: 21234 rows Table marc_blob_subfield: 5458 rows Table marc_breeding: 348 rows Table marc_subfield_structure: 1107 rows Table marc_subfield_table: 455964 rows Table marc_tag_structure: 98 rows Table marc_word: 687694 rows Table systempreferences: 67 rows The "Check MARC" function returns all OKAY. I am at a loss what to do next. Any advice from the more experienced Koha users? thanks, rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
Hi Rick On 22/05/2007, at 10:05 PM, Rick Welykochy wrote:
Hello to the list,
<snip>
Today we decided to upgrade to Koha 2.2.9 to fix the outstanding bugs.
After upgrading the database, the catalogue search still does not work. Every search on the OPAC quick search page returns the same result: one record, prolly the first in the biblio section of the database.
Standard question, is there anything in the error log that might explain what its doing Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131
Chris Cormack wrote:
After upgrading the database, the catalogue search still does not work. Every search on the OPAC quick search page returns the same result: one record, prolly the first in the biblio section of the database.
Standard question, is there anything in the error log that might explain what its doing
This is the only thing in the file opac-error_log: File does not exist: /usr/local/koha/opac/htdocs/opac-tmpl/css/en/includes/marc-editor.css Just as a side issue, that error is understandable since the only file by that name is found in the french area: opac/htdocs/opac-tmpl/css/fr/includes/marc-editor.css (And koha-error_log is empty) Hmmm, back to this issue. Given that the marc_* tables are populated and the biblio_* are as well, it is hard for me to understand why the search is failing. Admittedly I have not looked into the perl code. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
On 22/05/2007, at 10:53 PM, Rick Welykochy wrote:
Hmmm, back to this issue. Given that the marc_* tables are populated and the biblio_* are as well, it is hard for me to understand why the search is failing. Admittedly I have not looked into the perl code.
I wonder if its to do with MySQL version? Are you running version 5? Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131
Chris Cormack wrote:
I wonder if its to do with MySQL version? Are you running version 5?
Server version 5.0.32-Debian_7etch1 I am really at a loss how to proceed. Are there any testing suites for Koha? Can I perform a unit test on the DB interface or else an integration test on the search module? cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
Rick Welykochy wrote:
Server version 5.0.32-Debian_7etch1
BTW: The above version of MySQL was used for all my KOha installs, from 2.2.7 onwards. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
On 23/05/2007, at 11:36 AM, Rick Welykochy wrote:
Rick Welykochy wrote:
Server version 5.0.32-Debian_7etch1
BTW: The above version of MySQL was used for all my KOha installs, from 2.2.7 onwards.
From what I remember of the 2.2.7 install we made some changes to the SQL to make it mysql 5 compliant. Is it possible these changes were overwritten? Chris -- Chris Cormack chris.cormack@liblime.com VP Research and Development www.liblime.com LibLime +64 21 542 131
Chris Cormack wrote:
From what I remember of the 2.2.7 install we made some changes to the SQL to make it mysql 5 compliant.
Is it possible these changes were overwritten?
If that were the case, the MySQL statements would fail and the script would go into error. The changes to the SQL were not simply semantic - they were syntactic. e.g. refering to http://lists.katipo.co.nz/pipermail/koha/2006/010477.html Search.pm: < from biblio, biblioitems < biblio.biblionumber = bibliosubtitle.biblionumber < left join itemtypes on biblioitems.itemtype=itemtypes.itemtype ----
from biblioitems, biblio (biblio.biblionumber = bibliosubtitle.biblionumber) left join (itemtypes on biblioitems.itemtype=itemtypes.itemtype)
WHEREAS the 2.2.9 source has the following changes:
FROM biblio LEFT JOIN (biblioitems) ON (biblio.biblionumber = biblioitems.biblionumber) LEFT JOIN (itemtypes) ON (biblioitems.itemtype = itemtypes.itemtype)
I have not tested the effect of changing a natural join (2.2.7) to a left outer join (2.2.9) but perhaps that could have something to do with the search problem. Any insights most welcome. And the big Question: is anyone on the list using 2.2.9 with MySQL 5.0 successfully? cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
Rick Welykochy wrote:
After upgrading the database, the catalogue search still does not work. Every search on the OPAC quick search page returns the same result: one record, prolly the first in the biblio section of the database.
The tables are populated with records, as one would expect, e.g. here are some sample row counts:
Table biblio: 16473 rows Table biblio_framework: 0 rows Table biblioanalysis: 0 rows Table biblioitems: 16324 rows Table bibliosubject: 15820 rows Table bibliosubtitle: 3902 rows Table bibliothesaurus: 0 rows
Table branches: 10 rows Table items: 16448 rows
Table marc_biblio: 21234 rows Table marc_blob_subfield: 5458 rows Table marc_breeding: 348 rows Table marc_subfield_structure: 1107 rows Table marc_subfield_table: 455964 rows Table marc_tag_structure: 98 rows Table marc_word: 687694 rows
Table systempreferences: 67 rows
I am trying another search: that found on the Catalogue page in the (port 8080) Intranet area. The script is /cgi-bin/koha/MARCdetail.pl The symptoms in this case are much different. The browser never completes the request. This is because the web server goes into a tailspin, load average 6.0+, CPU at 100%, with mysql and perl churning away seemingly forever. Perhaps the query would have eventually stopped, but with the load avg climbing and the server brought to its knees I thought it best to terminate the web process before things got out of hand. Perhaps these symptoms might provide a bit more insight. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
Rick Welykochy wrote:
I am trying another search: that found on the Catalogue page in the (port 8080) Intranet area. The script is
/cgi-bin/koha/MARCdetail.pl
The symptoms in this case are much different. The browser never completes the request. This is because the web server goes into a tailspin, load average 6.0+, CPU at 100%, with mysql and perl churning away seemingly forever. Perhaps the query would have eventually stopped, but with the load avg climbing and the server brought to its knees I thought it best to terminate the web process before things got out of hand.
Perhaps these symptoms might provide a bit more insight.
I ran the above search again and decided to wait to see what happened. The Koha server eventually returned the results .... lots and lots of them. So many that my browser went a bit wonky. The good thing was that the Koha server handled the large search request fine and the load avg returned to normal. So it appears that the catalogue search in the Intranet area works fine. The problem remains with the OPAC search. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services Any belief that can't stand up to objective scrutiny is hardly worth having. -- LJ McIntyre
Rick Welykochy wrote:
The good thing was that the Koha server handled the large search request fine and the load avg returned to normal. So it appears that the catalogue search in the Intranet area works fine.
The problem remains with the OPAC search.
Any word on this? Our Catalogue (intranet) Search works fine. Our OPAC Search always fails, by returning only one record, the same record, all the time. What advice does the Koha project (and developers?) give for attacking a problem like this? We simply cannot deploy Koha in its current state. We are at a deadended. Any thoughts most appreciated. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services We should invade their countries, kill their leaders and convert them to Christianity. -- Anne Coulter of the "American Taliban"
participants (2)
-
Chris Cormack -
Rick Welykochy