Trackzilla upgrade?

Happy New Year folks,

For my sins I've inherited an old system that I need to upgrade and the guy that installed it left many years ago. It claims to be Trackzilla 4.4.2 and has release notes mentioning Trackzilla throughout but its clearly Bugzilla 4.4.2 under the skin.

I can't find any reference to Trackzilla on the internet that fits so does anyone know if it was an official customisation?

I tried to upgrade to bugzilla 4.4.13 but check-setup.pl failed with 

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?

Phil

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=3Dsingle&version=3D5.0.6&vie=
w=3DView+schema
http://schema.seyman.fr/bugzilla

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning
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=E4ftsf=FChr=
er Janine Galonska

On Monday, 4 January 2021 at 13:03:42 UTC, Thorsten Sch=C3=B6ning wrote:
> Guten Tag Phil C,=20
> am Montag, 4. Januar 2021 um 12:43 schrieben Sie:
> > I can't find any reference to Trackzilla on the internet that fits=20
> > 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=20
> opinion it's unlikely. Sounds to me like the term "Bugzilla" simply=20
> has been replaced throughout the codebase.=20
>=20
> I suggest getting the official GIT-repo of Bugzilla, checking out the=20
> tag for 4.4.2and simply comparing some files. This will reveal minor=20
> renames vs. an extension being available or really heavily customized=20
> codebase. You most likely need to know about such things to fix your=20
> update problem anyway.=20
>=20
> https://github.com/bugzilla/bugzilla/tree/release-4.4.2
> > Adding new column 'visibility_value_id' to the=20
> > 'cf_newserver_crb_r74_76_1k_and_r75_r77_no_fit' table...=20
> > DBD::mysql::db do failed: Duplicate column name=20
> > 'visibility_value_id' [for Statement "ALTER TABLE=20
> > cf_newserver_crb_r74_76_1k_and_r75_r77_no_fit ADD COLUMN=20
> > visibility_value_id smallint"] at Bugzilla/DB.pm line 590.=20
>=20
> > 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=20
> into place... ;-)=20
>=20
> Seriously, have a look at the mentioned table if the mentioned column=20
> really is available already. If so, this might be a hint that somebody=20
> wronlgy applied updates to the database in the past. Bugzilla uses a=20
> table to store the current version of the schema, including custom=20
> fields (cf_), customizations by extensions etc. in. Compared to that=20
> description checksetup.pl decided what to do and seems to think wrong=20
> in your case.=20
>=20
> The table is named "bz_schema" and simply contains some Perl hash=20
> structure, which can be saved and DIFFed against other contents of=20
> that table in other versions or alike. There's a viewer available for=20
> how the schema needs to look like officially:=20
>=20
> http://schema.seyman.fr/bugzilla/schema?action=3Dsingle&version=3D5.0.6&v=
iew=3DView+schema=20
> http://schema.seyman.fr/bugzilla=20
>=20
> Mit freundlichen Gr=C3=BC=C3=9Fen,=20
>=20
> Thorsten Sch=C3=B6ning=20
>=20
> --=20
> Thorsten Sch=C3=B6ning=20
> AM-SoFT IT-Service - Bitstore Hameln GmbH=20
>=20
> E-Mail: [email protected]=20
> Web: http://www.AM-SoFT.de/=20
>=20
> Telefon: 05151- 9468-55=20
> Fax: 05151- 9468-88=20
> Mobil: 0178-8 9468-04=20
>=20
> Firmensitz: Bitstore IT-Consulting, Frankfurter Allee 285, 10317 Berlin=
=20
> Steuernummer 037/230/30566, HR 27198, Amtsgericht Potsdam Gesch=C3=A4ftsf=
=C3=BChrer 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

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

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 fr=
om 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=20

Phil