The database update 16.06.00.028 fails with following error in an update from 3.22.19 to 16.11.08: Attempting upgrade to 16.06.00.028 (Bug 17135) ... DBD::mysql::st execute failed: Unknown column 'me.no_auto_renewal_after' in 'field list' [for Statement "SELECT `me`.`categorycode`, `me`.`itemtype`, `me`.`restrictedtype`, `me`.`rentaldiscount`, `me`.`reservecharge`, `me`.`fine`, `me`.`finedays`, `me`.`maxsuspensiondays`, `me`.`firstremind`, `me`.`chargeperiod`, `me`.`chargeperiod_charge_at`, `me`.`accountsent`, `me`.`chargename`, `me`.`maxissueqty`, `me`.`maxonsiteissueqty`, `me`.`issuelength`, `me`.`lengthunit`, `me`.`hardduedate`, `me`.`hardduedatecompare`, `me`.`renewalsallowed`, `me`.`renewalperiod`, `me`.`norenewalbefore`, `me`.`auto_renew`, `me`.`no_auto_renewal_after`, `me`.`reservesallowed`, `me`.`holds_per_record`, `me`.`branchcode`, `me`.`overduefinescap`, `me`.`cap_fine_to_replacement_price`, `me`.`onshelfholds`, `me`.`opacitemholds`, `me`.`article_requests` FROM `issuingrules` `me` WHERE ( ( `me`.`branchcode` = ? AND `me`.`categorycode` = ? AND `me`.`itemtype` = ? ) )" with ParamValues: 0='XXX', 1='STUDENT', 2='NORMAL'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832. It's missing the column no_auto_renewal_after which is not present at this time in the database. It's added later on with update 16.06.00.046. Could it be because the schema already has the column?
I'd suggest to remove the execution of this script from the updatedatabase.pl script and move it to the maintenance directory. The updatedatabase.pl script must not use C4 or Koha modules. The update entry could be replaced with a warning message to tell the admin they should execute the script.
(In reply to Katrin Fischer from comment #0) > The database update 16.06.00.028 fails with following error in an update > from 3.22.19 to 16.11.08: > > Attempting upgrade to 16.06.00.028 (Bug 17135) ... > DBD::mysql::st execute failed: Unknown column 'me.no_auto_renewal_after' > in 'field list' [for Statement "SELECT `me`.`categorycode`, > `me`.`itemtype`, `me`.`restrictedtype`, `me`.`rentaldiscount`, > `me`.`reservecharge`, `me`.`fine`, `me`.`finedays`, > `me`.`maxsuspensiondays`, `me`.`firstremind`, `me`.`chargeperiod`, > `me`.`chargeperiod_charge_at`, `me`.`accountsent`, `me`.`chargename`, > `me`.`maxissueqty`, `me`.`maxonsiteissueqty`, `me`.`issuelength`, > `me`.`lengthunit`, `me`.`hardduedate`, `me`.`hardduedatecompare`, > `me`.`renewalsallowed`, `me`.`renewalperiod`, `me`.`norenewalbefore`, > `me`.`auto_renew`, `me`.`no_auto_renewal_after`, `me`.`reservesallowed`, > `me`.`holds_per_record`, `me`.`branchcode`, `me`.`overduefinescap`, > `me`.`cap_fine_to_replacement_price`, `me`.`onshelfholds`, > `me`.`opacitemholds`, `me`.`article_requests` FROM `issuingrules` `me` > WHERE ( ( `me`.`branchcode` = ? AND `me`.`categorycode` = ? AND > `me`.`itemtype` = ? ) )" with ParamValues: 0='XXX', 1='STUDENT', > 2='NORMAL'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832. > > It's missing the column no_auto_renewal_after which is not present at this > time in the database. It's added later on with update 16.06.00.046. > > Could it be because the schema already has the column? Yes, looks like it happens because during this particular upgrade step DBIx schema is out of sync with the actual database structure, and CalcFine (after Bug 17599 got pushed ?) is prone to fail because of that. During upgrades from 16.05.03+ to 16.11.* or 17.05.*, there will be an attempt to re-run the script from Bug 17135, and it will fail - but at least the non-accruing FU fine records got already closed in earlier 16.05.03 upgrade step, so this error should be (relatively) harmless. Upgrades to 16.11+ from versions earlier than 16.05.03 are affected to a larger extent by this issue - execution of the script will fail, some non-accruing FU fines will remain unclosed, and they may get overwritten later on.
Oh crap this is still valid.
/me wonders if this can be close and 'RESOLVED WONTFIX' at this point?
We should have fixed it... but we haven't. I think closing now as WONTFIX makes sense as the versions affected are no longer maintained.