I'm getting error: Undefined subroutine &C4::AuthoritiesMarc::prepare called at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720. Here's the code from AuthoritiesMarc.pm ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef); 720=> my $sth = prepare("DELETE FROM auth_header WHERE authid=?"); $sth->execute($authid); The authid is being passed [correctly?] as a 4 digit integer|string: <http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&authid=2925> Any thoughts? Thanks Paul Tired old sys-admin
On 3 April 2011 10:48, Paul <paul.a@aandc.org> wrote:
I'm getting error: Undefined subroutine &C4::AuthoritiesMarc::prepare called at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720.
Here's the code from AuthoritiesMarc.pm
ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef); 720=> my $sth = prepare("DELETE FROM auth_header WHERE authid=?"); $sth->execute($authid);
The authid is being passed [correctly?] as a 4 digit integer|string: <http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&authid=2925>
What version of Koha Paul? In the master branch in git, line 720 is my $sth = $dbh->prepare("DELETE FROM auth_header WHERE authid=?"); The same in the 3.2.x branch. That line was changed first on the 24th of Feb, which introduced the bug, it was fixed on the 28th, git blame tells me 2011-02-28 08:30:07 +0000 to be exact. But that line was fine in both 3.2.4 and 3.2.5 (and earlier releases) and in fact was never released in the form you have) So I suspect you must have applied a patch manually, and not the follow up, or installed from git sometime in the 4 days between the security fix, and the typo fix. So I suspect you want to upgrade to 3.2.6 (the latest stable release) or upgrade your git checkout to the lastest HEAD of the 3.2.x branch Chris
At 11:21 AM 4/3/2011 +1200, Chris Cormack wrote:
On 3 April 2011 10:48, Paul <paul.a@aandc.org> wrote:
I'm getting error: Undefined subroutine &C4::AuthoritiesMarc::prepare called at /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720.
Here's the code from AuthoritiesMarc.pm
 ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef); 720=>   my $sth = prepare("DELETE FROM auth_header WHERE authid=?");     $sth->execute($authid);
The authid is being passed [correctly?] as a 4 digit integer|string:
<http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&authid=2925>
What version of Koha Paul?
Hi Chris, 3.02.05.000 We got koha-3.02.05.tar.gz downloaded 25 Feb at 8:18pm GMT (internal files dated 2/24/2011 4.41pm) - talk about timing ;={ What's involved in upgrading to 3.2.6 ? When we last did the "upgrade" from koha-3.02.03.tar (internal files dated 1/22/2011 6.35pm), it turned out to be a complete install - so we had to go back and redo all our mods (mostly css and custom modules) but it was still half a day's work. Thank $deity Koha adds suffixes to old files, but still... Or, what's involved with "upgrade your git checkout to the lastest HEAD of the 3.2.x branch"? Again, we're in semi-production mode at the moment, staff training has started, and I really want to keep as stable as possible; and I do not, (for budgetary reasons) have a sandbox available at the moment - hopefully Q3 this year. So - guess I just plug in a new AuthoritiesMarc.pm - for exact reference is date/time good enough? Also, are there any other 3.02.05 files that I need to look at? Many thanks - Paul
In the master branch in git, line 720 is my $sth = $dbh->prepare("DELETE FROM auth_header WHERE authid=?");
The same in the 3.2.x branch.
That line was changed first on the 24th of Feb, which introduced the bug, it was fixed on the 28th, git blame tells me 2011-02-28 08:30:07 +0000 to be exact.
But that line was fine in both 3.2.4 and 3.2.5 (and earlier releases) and in fact was never released in the form you have) So I suspect you must have applied a patch manually, and not the follow up, or installed from git sometime in the 4 days between the security fix, and the typo fix.
So I suspect you want to upgrade to 3.2.6 (the latest stable release) or upgrade your git checkout to the lastest HEAD of the 3.2.x branch
Chris
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>
* Paul (paul.a@aandc.org) wrote:
What version of Koha Paul?
Hi Chris,
3.02.05.000
We got koha-3.02.05.tar.gz downloaded 25 Feb at 8:18pm GMT (internal files dated 2/24/2011 4.41pm) - talk about timing ;={
What's involved in upgrading to 3.2.6 ? When we last did the "upgrade" from koha-3.02.03.tar (internal files dated 1/22/2011 6.35pm), it turned out to be a complete install - so we had to go back and redo all our mods (mostly css and custom modules) but it was still half a day's work. Thank $deity Koha adds suffixes to old files, but still...
Ahh if you have custom modules then don't do this. I assume you have all your custom work under version control? Or maybe not if I read below
Or, what's involved with "upgrade your git checkout to the lastest HEAD of the 3.2.x branch"? Again, we're in semi-production mode at the moment, staff training has started, and I really want to keep as stable as possible; and I do not, (for budgetary reasons) have a sandbox available at the moment - hopefully Q3 this year.
If you were running from git, you could just create a local branch, merge in the HEAD of the 3.2.x branch test and if all goes well you are done, if not, just checkout your old branch (and restore your database from the backup you did). I strongly suggest doing your development in a maintainable way, under a version control system so that you can merge in from upstream. Or just run released versions. But untracked (by a version control system) changes will always cause you problems any time you go to upgrade.
So - guess I just plug in a new AuthoritiesMarc.pm - for exact reference is date/time good enough? Also, are there any other 3.02.05 files that I need to look at?
You could try that, you would need to be careful that no other changes were made in that file, that rely on changes in other files. If you find the commit in it, you could cherry-pick or find the patch file in the koha-patches list and apply that. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
participants (3)
-
Chris Cormack -
Chris Cormack -
Paul