3.8.7 > 3.8.8 MySql Error reported

[FreshWebServs]

Hi,
I've just updated a site from 3.8.7 to 3.8.8 & got the following error report:

Code: Select all

JInstaller: :Install: Error SQL Duplicate entry '480' for key 'PRIMARY'
Files Update: SQL error file DB function failed with error number 1062 
Duplicate entry '480' for key 'PRIMARY'
SQL =

Code: Select all

INSERT INTO `#__extensions` (`extension_id`, `package_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `manifest_cache`, `params`, `custom_data`, `system_data`, `checked_out`, `checked_out_time`, `ordering`, `state`) VALUES
(480, 0, 'plg_system_sessiongc', 'plugin', 'sessiongc', 'system', 0, 1, 1, 0, '', '', '', '', 0, '0000-00-00 00:00:00', 0, 0);

However, it is also reported that the site is now 3.8.8.

The front end works as expected, as does admin.

Any suggestions?

Thanks,
Eddie

[Webdongle]

Was the original install a 3rd party quick/template install ?

[FreshWebServs]

Hi,
Don't know, tbh. I 'inherited' the site. That said, I wouldn't be surprised if it was a template install. Any way of checking?
Thanks,

[sozzled]

Don't know, tbh. I 'inherited' the site. That said, I wouldn't be surprised if it was a template install. Any way of checking?

The "usual" way of checking if the website was created with one of those "quick" installs (especially if you "inhererited" the website) is when you can't upgrade it. I realise that's not a scientific explanation but, TBH, we receive hundreds—if not thousands—of requests about being unable to update Joomla because of these so-called "quick" installs.

I'm not saying that there ought to be a law against using "template installations" but, by the same token, you get what you didn't pay for when you use them. Caveat emptor, and all that. Would I use a "template install" as opposed to spending 10 minutes to create a brand new Joomla website that works? Not on your life do I use those scripted/quick installation things!

[deleted user]

Contrary to popular opinion, an error like this would not solely be because you used a quickstart package to set up a Joomla site. There are scenarios out there where the auto increment value on the database can be reset, and since core places value on setting the default auto increment for the extensions table to 10000 and trying to hard reserve the 1-9999 ID range, an upgrade can error out if auto increment was reset and core tries to add a new extension which is using an ID already in use by the table through no fault of the user.

So thanks for the long drawn out speech on why quick starts are bad without providing any real useful info to help the user.

[sozzled]

All very true, @mbabker. The question asked was about "any way of checking" if an "inherited" J! website was built using a quick installation script. I don't know of any way of checking if that occurs. My "long drawn-out" observations are based on my experience seeing these situations arise as the result of using those "quick" installation methods and, in most cases, where people have not used those methods (and have maintained their websites vigilantly over time) they won't encounter the problems mentioned here.

We don't see the complete picture. We only see the cases where people have problems; we rarely see written "I used an installation procedure developed by a template developer and I have zero problems updating J!", do we?

The root of the problem lies within the database: how people get there—how they move on from there—are complex and there's no one-size-fits-all explanation.

[Webdongle]

viewtopic.php?f=714&t=793531
And we can look at the extensions and Template(s). That will give a clue as to if it was a Template install. Not important but it would be nice to know if the cause was because of a Template install.