What version WERE you running?

What does this page say on your site?

http://example.com/administrator/index.php?option=com_installer&view=database

What version WERE you running?

3.10

What does this page say on your site?

http://example.com/administrator/index.php?option=com_installer&view=database

There are tables not up to date!

CMS JoomlaJoomla! 3: Sistema de gestión de contenidos | Sitio | Archivo | ¡Advertencia: La base de datos no está actualizada! | 3.10.0-2021-05-28 | ‎4.0.0 | No aplicable

If I give it to correct and apply the database update, the control panel does not show any option, it is empty.

CMS JoomlaJoomla! 3: Sistema de gestión de contenidos | Sitio | Archivo | One Problem | 4.0.0-2021-08-17 | ‎4.0.0 | No aplicable

The problem is relative to the jooomla_finder_taxonomy, idx_level index.

@richard67 is the best man to understand this, he has been very close to the db migration path. Please wait and Im sure he will pop by soon.

What database type and exact version do you run? It should show in the system information of 3.10?

I can't help soon because am busy, sorry.

As it is an update to 4.0 I hope it is not a productive live site but a testing site.

@mikesmith500 Are there SQL statements logged in the update log file "adminstrator/logs/joomla_update.php"? If so: Which is the last one?

@richard67 No rush, I have backups.

2021-08-17T17:10:43+00:00 INFO 90.167.222.44 update Consulta ejecutada desde el archivo 4.0.0-2018-03-05. Texto de la consulta: INSERT INTO #__extensions (name, type, element, folder, client_id, . 2021-08-17T17:10:43+00:00 INFO 90.167.222.44 update Consulta ejecutada desde el archivo 4.0.0-2018-03-05. Texto de la consulta: DELETE FROM #__extensionsWHEREtype= 'library' ANDelement= 'phputf8';. 2021-08-17T17:10:43+00:00 INFO 90.167.222.44 update Consulta ejecutada desde el archivo 4.0.0-2018-03-05. Texto de la consulta: DELETE FROM#__extensionsWHEREtype= 'plugin' ANDelement= 'p3p' ANDf.
2021-08-17T17:10:43+00:00 INFO 90.167.222.44 update Limpieza posterior a la instalación.
2021-08-17T17:10:43+00:00 INFO 90.167.222.44 update La actualización a la versión 4.0.0 se ha completado.çç

What database type and exact version do you run?

Translation: What version of Mysql or postgres are you using? Go to

http://example.com/administrator/index.php?option=com_admin&view=sysinfo

and Click download as text and then upload that file here.

I can't really find any reason for the Error SQL Duplicate entry '1' for key 'PRIMARY' error in that SQL script or the one after it below an insert into extensions statement. we do not use the primary key 1 anywhere. So it could become complicated. An SQL export of the database could help to find the reason. Do you have a way to provide that for download? You can remove any content records from it or stuff like the user table where you think there is confidential data,

What database type and exact version do you run? It should show in the system information of 3.10?

I have two Joomla sites on the same server, one has migrated fine, and the other has not.

dbserver: mysql
dbversion: 5.5.5-10.3.29-MariaDB-0+deb10u1
dbcollation: utf8mb4_general_ci
dbconnectioncollation: utf8mb4_general_ci
phpversion: 7.4.22
server: Apache
sapi_name: fpm-fcgi
version: Joomla! 3.10.0 Stable [ Daraja ] 14-August-2021 11:55 GMT

@mikesmith500 Please double check if the 2 sites on your server really use different databases or - if same database - use at least different table prefixes.

For this, check the "configuration.php" files of the 2 (or if more, all) Joomla installation. The database is variable "$db", the server where this database is located is "$host" and the table prefix is "$dbprefix". If these 3 values are same for 2 sites, they share the same database (which is a mistake).

Please check and report back if the site which has the problem maybe by mistake uses the same database as the other site which has been updated before and where it worked well. Thanks in advance.

@richard67 The sites are totally independent, with separate databases. There must be something in the database that causes the problem. I can send the database privately if necessary.

@richard67 I can send the database privately if necessary.

@mikesmith500 That could be very helpful. Go to the contact form of my website https://www.richard-fath.de/en/contact.html and send me a message, using your email address as sender. I will reply to it and then you have my private email address. Then you can send me a zip or so with an SQL export. I hope it's not too big. Otherwise we have to find another way.

@richard67 Agree. I will do.

@mikesmith500 Thanks for the database export.

As it turned out and you have confirmed in email, there were already tables for the new Joomla 4 workflow present in the database before the update from 3.10 to 4.0.

The reason is that after a previous try to update that 3.10 site to a 4.0 RC, the restore of the backup did restore the 3.10 files and data but did not delete the new tables from 4.0.

Again thanks for the help with investigating that, and I'm happy we could sort that out.

Closing as not a core issue.

@richard67 I have the very same problem and I hope the solution might be the same. Would you please be so kind and tell me the name of this tables for the new Joomla 4 workflow? Thank you very much in advance.

@richard67 I have the very same problem and I hope the solution might be the same. Would you please be so kind and tell me the name of this tables for the new Joomla 4 workflow? Thank you very much in advance.

@fjmavea The solution is to have made a backup before starting the update, and if the update fails restore the database backup into an empty database and the files backup into an empty folder. If you use Akeeba for that, they have a FAQ on their homepage which contains information on which options to chose in Akeeba backup to make such a complete restoration of a backup. It is not enough just to remove the workflow tables because if that is solved, the next problem will come with other tables new in J4.

In general the SQL scripts run on update are here: https://github.com/joomla/joomla-cms/tree/4.0-dev/administrator/components/com_admin/sql/updates/mysql . They are run in order of first the version number and then (if same version) the date from old to new, i.e. first runs 4.0.0-2018-03-05.sql, then 4.0.0-2018-05-15.sql and so on. In the log file "aministrator/logs/joomla_update.php" of the failed attempt to update you can see which SQL statements have been executed from which SQL script and so find out which was the last one which was executed. The next SQL statement after that is the one which broke. With this information you know which statements you have to revert in order to go back to the previous state (if not having a backup).

@richard67 thank you. Restoring the database backup into an empty database should have made the trick if I had known that before, but this option is gone because I cannot go back in time and warn my younger self.
Thanks for the heads-up to the SQL scripts. I think I'm going to have a look in there for any table that is added.

Dear Sirs:

We've gone through this process some 9 times now. The most recent attempts have all ended with Ver. 4 and the Primary Key problem. We have been restoring with Akeeba backup but obviously something is not working. We have access to our database if that would help. We suspect that the personnel in the Joomla! site are tired of our posting so we are happy to have found this site. Maybe with your help we can get this upgrade finished.

Have a great evening and please stay safe! :)

Hello folks,

6 months later, I do have exactly the same issue than @ghost.
However, I do not remember to have tried to update to J4 before my Akeeba backup.
Is there any column I should be looking for in the database.

Linux 5.11.0-44-generic #48~20.04.2-Ubuntu SMP Tue Dec 14 15:36:44 UTC 2021 x86_64
mysql 5.6.50
latin1_swedish_ci
utf8mb4_general_ci
php 7.4.3
Apache/2.4.41 (Ubuntu)
apache2handler
Joomla! 4.0.5 Stable [ Furaha ] 11-December-2021 20:52 GMT

Thanks a lot,

@NicolasDequeant Check if in the database backup before the update there are tables with names starting with #__workflow (replace #__ with your actual database prefix). If so, then there was an attempt to update to 4 before the current one, and the backup contains remainders of that. If not then it's something different.

@richard67 That's it. I do not remember to have done an attempt before backing up. At the end of the day, all entries look like less than 4 days old. I may find a proper back-up and start again to delete all my 3rd party's extensions.

(My production database has no #_workflow tables :-) )

Thanks a lot.

So my take is that if we had made a previous attempt and somewhere along the way have lost a virgin J3 database, we are never getting out of J3? After at least 20 tries, it certainly appears hopeless.