[rt-users] RT 3.4.1 upgrade oddness?

[Rich West]

Grr.. it worked for my test tickets, but other tickets are barfing the 
same way!

It seems like, for some reason, it is having problems with the column 
Transactions_1.Ticket (which is an alias for Transactions.Ticket, to 
which the Transactions table doesn't have a column named Ticket!).

I have gone through the etc/upgrade/3.3.0 and etc/upgrade/3.3.11 files 
by hand... everything has been applied properly.  Any ideas as to the 
cause of this column not existing or even being needed in the first place.

[Tue Mar 15 16:41:13 2005] [error] [client 67.160.250.30] FastCGI: 
server "/opt/rt3/bin/mason_handler.fcgi" stderr: 
RT::Handle=HASH(0x9b9966c) couldn't execute the query 'SELECT DISTINCT 
main.Id AS id, main.Filename AS filename, main.ContentType AS 
contenttype, main.Headers AS headers, main.Subject AS subject, 
main.Parent AS parent, main.ContentEncoding AS contentencoding, 
main.ContentType AS contenttype, main.TransactionId AS transactionid, 
main.Created AS created FROM Attachments main , Transactions 
Transactions_1, Tickets Tickets_2  WHERE ((Tickets_2.EffectiveId = 
'12561')) AND ((Transactions_1.Ticket = Tickets_2.id)) AND 
((main.TransactionId = Transactions_1.id)) ' at 
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 494., 
referer: http://site.org/
[Tue Mar 15 16:41:13 2005] [error] [client 67.160.250.30] FastCGI: 
server "/opt/rt3/bin/mason_handler.fcgi" stderr: DBD::mysql::st execute 
failed: Unknown column 'Transactions_1.Ticket' in 'where clause' at 
/usr/lib/perl5/site_perl/5.8.3/DBIx/SearchBuilder/Handle.pm line 480., 
referer: http://site.org/


I'd hate to have to down the software to back out of the whole thing 
now... :(

-Rich

> Actually, it was a warning about a duplicate column, but unfortunately 
> I lost it when I closed the terminal session. :(
>
> However, I think you might be right about stale stuff hanging around.. 
> I downed the web server again, made sure that all of the mason 
> handlers were down, then brought up the web server.  Since then, all 
> tests have gone through with no problems.
>
> It looks as if the problem may have been temporary or due to a FCGI 
> process and subsequent mason_handler process hanging around after the 
> upgrade.  I'm keeping eyes on things, though..
>
> -Rich
>
>
>
>>> So, with that nice experience under our belt, we took on the task of 
>>> upgrading on of our clients' installations of Request Tracker from 
>>> 3.2.2 (we keep the versions in sync for ease of maintenance) to 
>>> 3.4.1 and, well, this upgrade didn't go as smoothly.  One of the 
>>> upgrade scripts (3.3.0 - schema) generated an error, but we pressed 
>>> onwards.
>>>
>>>   
>>
>>
>> Uh. What sort of error? If your schema upgrade failed, the system
>> ain't gonna work.  It also sounds like you might have stale mason
>> templates sitting around.
>>
>>     Jesse
>>