Reinstalling the FAQ module resolved this problem, although it resulted
in the loss of the FAQ data.
-------- Original Message --------
Subject: Problems Updating OTRS
Date: Tue, 21 Jul 2009 14:13:00 -0600
From: Erik Sejr
To: otrs@otrs.org
Hi,
We had a old version of OTRS running (2.0.4) which we wanted to get
up-to-date. After reading the UPGRADE file for 2.1.x, 2.2.x, 2.3.x I
decided to do this update incrementally, 2.0.4 -> 2.1.8 -> 2.2.8 -> 2.3.4.
The first 2 upgrades (2.0.4 -> 2.1.8 and 2.1.8 -> 2.2.8) went smoothly,
no errors or problems were found. We did some brief testing between each
update, then did the next one.
Our OTRS installation has been running for over 4 years, and since then
the database has gotten quite large, the database is around 2.77 GB, the
DB upgrades took quite a while but all completed with no errors until I
attempted the 2.2.8 -> 2.3.4 upgrade. This is where the problems started.
After the 2.3.4 upgrade, despite the database error generated by the
migration script "Link already exists between these two objects in
opposite direction!" (sorry, I no longer have the exact error, unless
the script logged it somewhere) OTRS seemed to work. The only thing that
seems to be broken is the FAQ. The errors I got complained of missing
columns in the faq_item table. I noticed a pattern that indicated these
columns had been renamed and figured that the upgrade script had not
completed its work properly, so I renamed them manually:
mysql> alter table faq_item change column created_by create_by int(11);
Query OK, 5 rows affected (0.01 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql> alter table faq_item change column created create_time datetime;
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql> alter table faq_item change column changed_by change_by int(11);
Query OK, 5 rows affected (0.01 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql> alter table faq_item change column changed change_time datetime;
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
After renaming the columns in question the table looks like this:
mysql> show columns in faq_item;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| f_number | varchar(200) | NO | | | |
| f_subject | varchar(200) | YES | | NULL | |
| f_name | varchar(200) | NO | UNI | | |
| f_language_id | smallint(6) | NO | | 0 | |
| state_id | smallint(6) | NO | | 0 | |
| category_id | smallint(6) | NO | | 0 | |
| f_keywords | text | YES | | NULL | |
| f_field1 | text | YES | | NULL | |
| f_field2 | text | YES | | NULL | |
| f_field3 | text | YES | | NULL | |
| f_field4 | text | YES | | NULL | |
| f_field5 | text | YES | | NULL | |
| f_field6 | text | YES | | NULL | |
| free_key1 | varchar(80) | YES | | NULL | |
| free_value1 | varchar(200) | YES | | NULL | |
| free_key2 | varchar(80) | YES | | NULL | |
| free_value2 | varchar(200) | YES | | NULL | |
| free_key3 | varchar(80) | YES | | NULL | |
| free_value3 | varchar(200) | YES | | NULL | |
| free_key4 | varchar(80) | YES | | NULL | |
| free_value4 | varchar(200) | YES | | NULL | |
| create_time | datetime | YES | | NULL | |
| create_by | int(11) | YES | | NULL | |
| change_time | datetime | YES | | NULL | |
| change_by | int(11) | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
26 rows in set (0.00 sec)
Now the FAQS that previously existed started to show up in the list. The
database errors in the system log went away and I was able to create new
items without database errors. However, if I try to view any item I get
an error page with the following:
Software error:
Can't locate object method "AllLinkedObjects" via package
"Kernel::System::LinkObject" at ../..//Kernel/Modules/FAQ.pm line 514.
I'm not too worried about our existing FAQS, there are very few and they
are easily re-created, so if deleting the faq_item table and recreating
it is a solution I can do that, but I am curious if anyone knows how the
database can be properly repaired from the problematic upgrade without
losing data.
Thanks.
