http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167
--- Comment #179 from Chris Nighswonger <[email protected]> --- (In reply to comment #178) > > - BUG: Koha fails to pick up on the version change, and I am taken to > > mainpage.pl > > Yes, a line has to be replaced by the RM when this patch will be pushed (see > installer/instal.pl l.323 to set $koha39 with your last (+1) version number. I'll test this out today. > > - Tested install of updates by clicking "Update All." The PL file applied > > fine while the SQL file failed due to some SQL syntax error. > > - Text of error as displayed in the interface: "update_sample -- Error : > > 1064 => You have an error in your SQL syntax; check the manual that > > corresponds to your MySQL server version for the right syntax to use near > > 'INSERT INTO `systempreferences` VALUES ('TestSyspref3','2','set the level > > of err' at line 2;" > > - BUG: A quick look at the SQL file shows that the SQL for the "complex" > > example is correct; I'm assuming that there is a bug in the updater code. > > I can't reproduce that. Could you provide your test files please? I used the included sample files: installer/data/mysql/versions/update_sample.pl.sample installer/data/mysql/versions/update_sample.sql.sample > > > - BUG: I was not given the option of marking the aforementioned update as > > applied and consequently could not navigate away from the updater interface. > > This was unexpected behavior to me, as I would have expected to be able to > > return to normal operation of the staff interface in spite of the update > > failing. This probably needs to be added. If we do not want to permit > > forcing of this sort of thing, we should offer the user the option of > > completeing the updates at a later time perhaps setting a highly visible > > notification on the staff homepage to that effect. In any case, a more > > graceful recovery should be possible since we don't know the circumstances > > surrounding the user when such failure occurs. > > If a .pl file raises an error (here a syntax error), the queries are not > executed (inevitably). So there are no entry in the sql tables and we don't > know the "history" of this file. On master, the RM will not push an > unexecutable file; on a dev install the developper will know what happen and > will have to fix that (a simple way is to remove or move the file out of the > versions directory). Ok -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
