Migration issues from ancient 2.2.5 to 3.x
Hi all, I intend to migrate from an ancient in-production system - 2.2.5 running on FC4 to 3.10.4 running on Debian. As the first step I'm trying to move the data into Koha 3.0. So far I've tried to follow : 1) http://wiki.koha-community.org/wiki/Upgrading_2.2 2) http://lists.katipo.co.nz/public/koha/2011-August/030213.html Here what I have done. 1. Setup a VM running Koha 3.0 on Ubuntu 8.04 2. Taken a DB dump of 2.2.5 with Drop table if exist syntax. 3. Dropped the 3.0's tables from the DB and imported the 2.2.5 db 4. Followed the instructions from the Wiki article. Thing seems to work and I can login etc. However, a whole load of system preferences are missing from the db even after going through the 22_to_30 scripts Specifically I'm missing : StaffClient TemplateEncoding : utf-8 StaffClient Intranetcolorstylesheet : blue.css (to have some blue colors. This step is not required, you can skip it) StaffClient Template : prog What do you suggest I do? tia, -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org
Hi, On Fri, Apr 12, 2013 at 9:32 AM, Indranil Das Gupta <indradg@gmail.com> wrote:
However, a whole load of system preferences are missing from the db even after going through the 22_to_30 scripts
Specifically I'm missing :
StaffClient TemplateEncoding : utf-8 StaffClient Intranetcolorstylesheet : blue.css (to have some blue colors. This step is not required, you can skip it) StaffClient Template : prog
What do you suggest I do?
Fortunately, just adding the missing system preferences will do the right thing. A quick and dirty way to get them in with the default values would be to [1] Create a unique index on systempreferences.variable. [2] Run the following; the unique index will prevent duplicates system preferences from being loaded: mysql [connection info] --force < installer/data/mysql/sysprefs.sql [3] Drop the unique index. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Should that be the case, I wonder if such a unique index on systempreferences.variable. would be welcome as a permanent feature. Unless all sql scripts check for already existing entries so that they perform an update instead of insert, the index would at least ensure that no duplicates are created. On the other hand of course, this would mean that some sql scripts may need re-visiting in order to ensure proper error trapping after every insert in systempreferences, but this may be better than having to deal with spurious errors during production, stemming from multiple occurrences of the same variable in systempreferences. Do you agree or have I got it wrong? MP -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Galen Charlton Sent: Friday, April 12, 2013 8:14 PM To: Indranil Das Gupta Cc: koha Subject: Re: [Koha] Migration issues from ancient 2.2.5 to 3.x Hi, On Fri, Apr 12, 2013 at 9:32 AM, Indranil Das Gupta <indradg@gmail.com> wrote:
However, a whole load of system preferences are missing from the db even after going through the 22_to_30 scripts
Specifically I'm missing :
StaffClient TemplateEncoding : utf-8 StaffClient Intranetcolorstylesheet : blue.css (to have some blue colors. This step is not required, you can skip it) StaffClient Template : prog
What do you suggest I do?
Fortunately, just adding the missing system preferences will do the right thing. A quick and dirty way to get them in with the default values would be to [1] Create a unique index on systempreferences.variable. [2] Run the following; the unique index will prevent duplicates system preferences from being loaded: mysql [connection info] --force < installer/data/mysql/sysprefs.sql [3] Drop the unique index. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi, On Fri, Apr 12, 2013 at 11:21 PM, Manos PETRIDIS <egpetridis@yahoo.com> wrote:
Should that be the case, I wonder if such a unique index on systempreferences.variable. would be welcome as a permanent feature. Unless all sql scripts check for already existing entries so that they perform an update instead of insert, the index would at least ensure that no duplicates are created. [snip] Do you agree or have I got it wrong?
I agree that having a unique constraint on systempreferences.variable column makes sense. I've opened bug 10039 [1] for this proposal. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10039 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (3)
-
Galen Charlton -
Indranil Das Gupta -
Manos PETRIDIS