Upgrading database fails with duplicate column name error

Hi there

I’m doing a trial migration of our RT installation from 4.0.7 on Debian 7 to 4.4.1 on Ubuntu 16.04.

I’ve installed and configured successfully but I am now trying to bring the DB up to date using the make upgrade-database command. I ran successfully until 4.1.1 whereupon it failed with the following error:

Processing 4.1.1
Now populating database schema.
[2741] [Wed May 31 13:37:55 2017] [critical]: DBD::mysql::st execute failed: Duplicate column name ‘Disabled’ at /tmp/rt-4.4.1/sbin/…/lib/RT/Handle.pm line 552. (/tmp/rt-4.4.1/sbin/…/lib/RT.pm:390)
DBD::mysql::st execute failed: Duplicate column name ‘Disabled’ at /tmp/rt-4.4.1/sbin/…/lib/RT/Handle.pm line 552.
Makefile:389: recipe for target ‘upgrade-database’ failed
make: *** [upgrade-database] Error 9

This is very similar to a post I found on this site here: Upgrade-database from 4.0.8 to 4.4.0rc2 fails - his eventual fix was just to keep trying until it started working. I’ve tried it several times to no avail.

Some detective work:

These tables have column called disabled:

mysql> SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME IN (‘Disabled’) AND TABLE_SCHEMA=‘rt_scm’;
±------------------------+
| TABLE_NAME |
±------------------------+
| CachedGroupMembers |
| Classes |
| CustomFields |
| FM_Classes |
| ObjectCustomFieldValues |
| Principals |
| Queues |
| Scrips |
| Tickets |
±------------------------+

I checked each table and each one does indeed have one “Disabled” column but I have no idea which one is potentially the problem.

Can any one suggest how I might get around this?

Thanks in advance
Simon

I’ve been doing a similar migration upgrade (from 4.0.24 on Ubuntu 12.04 to 4.4.1 on Ubuntu14.04, postgres database) and hit a similar problem. It appears to me that at least one of the database upgrade scripts is not idempotent.

Or to put it another way, if you run the upgrade and it fails at certain steps then you can’t just run it again. You either need to manually patch up the database so the ‘failed’ stage is complete and upgrade from there on or you need to reload the database again at the original database level and upgrade from the start again. The upgrade steps do things that cause them to fall over if they try to run the same change on the database again.

(as a side note… I am using Ubuntu 14.04 as the target OS because Ubuntu 16.04 runs a version of perl that reports lots of errors into the system log of the form “Redundant argument in printf at /usr/local/share/perl/5.22.1/Convert/ASN1/Debug.pm line 101 line 755. (/usr/local/share/perl/5.22.1/Convert/ASN1/debug.pm:101)’”

I decided I couldn’t live with that on a production box and didn’t feel like downgrading Perl on Ubuntu 16.04… or waiting for the fix to be backported to Perl 5.22.1)

Your error points to line 522 in the file /tmp/rt-4.4.1/sbin/…/lib/RT/Handle.pm
Have you looked at the file? It will probably tell you which table.

/jeff

Hi Jeff

Yep, I looked there. It’s not particularly helpful:

local $SIG{WARN} = sub {};
my $is_local = 0;
$dbh->begin_work or return (0, "Couldn’t begin transaction: ". $dbh->errstr);
foreach my $statement (@schema) {
if ( $statement =~ /^\s*;$/ ) {
$is_local = 1; next;
}

    my $sth = $dbh->prepare($statement)
        or return (0, "Couldn't prepare SQL query:\n$statement\n\nERROR: ". $dbh->errstr);
    unless ( $sth->execute or $is_local ) {                   <<------ LINE 552
        return (0, "Couldn't run SQL query:\n$statement\n\nERROR: ". $sth->errstr);