Re: Trackzilla upgrade?

On Monday, 4 January 2021 at 13:28:37 UTC, Phil C wrote:
> On Monday, 4 January 2021 at 13:03:42 UTC, Thorsten Schöning wrote: 
> > Guten Tag Phil C, 
> > am Montag, 4. Januar 2021 um 12:43 schrieben Sie: 
> > > I can't find any reference to Trackzilla on the internet that fits 
> > > so does anyone know if it was an official customisation? 
> > I'm since 2005 on this list and can't remember that name, so in my 
> > opinion it's unlikely. Sounds to me like the term "Bugzilla" simply 
> > has been replaced throughout the codebase. 
> > 
> > I suggest getting the official GIT-repo of Bugzilla, checking out the 
> > tag for 4.4.2and simply comparing some files. This will reveal minor 
> > renames vs. an extension being available or really heavily customized 
> > codebase. You most likely need to know about such things to fix your 
> > update problem anyway. 
> > 
> > https://github.com/bugzilla/bugzilla/tree/release-4.4.2 
> > > Adding new column 'visibility_value_id' to the 
> > > 'cf_newserver_crb_r74_76_1k_and_r75_r77_no_fit' table... 
> > > DBD::mysql::db do failed: Duplicate column name 
> > > 'visibility_value_id' [for Statement "ALTER TABLE 
> > > cf_newserver_crb_r74_76_1k_and_r75_r77_no_fit ADD COLUMN 
> > > visibility_value_id smallint"] at Bugzilla/DB.pm line 590. 
> > 
> > > Is it likely I can fix that and get back to a working setup? 
> > The working setup can easily be achieved by putting your last backup 
> > into place... ;-) 
> > 
> > Seriously, have a look at the mentioned table if the mentioned column 
> > really is available already. If so, this might be a hint that somebody 
> > wronlgy applied updates to the database in the past. Bugzilla uses a 
> > table to store the current version of the schema, including custom 
> > fields (cf_), customizations by extensions etc. in. Compared to that 
> > description checksetup.pl decided what to do and seems to think wrong 
> > in your case. 
> > 
> > The table is named "bz_schema" and simply contains some Perl hash 
> > structure, which can be saved and DIFFed against other contents of 
> > that table in other versions or alike. There's a viewer available for 
> > how the schema needs to look like officially: 
> > 
> > http://schema.seyman.fr/bugzilla/schema?action=single&version=5.0.6&view=View+schema 
> > http://schema.seyman.fr/bugzilla 
> > 
> > Mit freundlichen Grüßen, 
> > 
> > Thorsten Schöning 
> > 
> > -- 
> > Thorsten Schöning 
> > AM-SoFT IT-Service - Bitstore Hameln GmbH 
> > 
> > E-Mail: [email protected] 
> > Web: http://www.AM-SoFT.de/ 
> > 
> > Telefon: 05151- 9468-55 
> > Fax: 05151- 9468-88 
> > Mobil: 0178-8 9468-04 
> > 
> > Firmensitz: Bitstore IT-Consulting, Frankfurter Allee 285, 10317 Berlin 
> > Steuernummer 037/230/30566, HR 27198, Amtsgericht Potsdam Geschäftsführer Janine Galonska
> Thanks Thorsten those all sound like good suggestions. 
> 
> I'll post back what I find out and what I do to fix it if I manage it. 
> 
> Phil
Hi Thorsten,

Following your advice I was able to complete the upgrade.

I check the custom fields screen in admin->preferences and found that the problem field was marked as obsolete. 

I was able to use the delete option to remove it so it doesn't seem like it was ever used. The checksetup.pl then completed ok so I've now upgraded from 4.4.2 to 5.0.6.

I wonder if the error was produced partly because we had an obsolete field that was never used and hence not fully populated in the database.

Anyway I have it all upgraded and working now so thanks for your help 

Phil
_______________________________________________
support-bugzilla mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put [email protected] in the To: field when you reply.