# Outstanding queries after upgrade to 4.4.5

**URL:** <https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884>\
**Category:** Mautic 4 Install/Upgrade Support\
**Created:** [January 27, 2023, 7:27pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884 "2023-01-27T19:27:38Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgtbhaji](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/sgtbhaji/32/637_2.png) [@sgtbhaji](https://forum.mautic.org/u/sgtbhaji)\
**Post date:** [January 27, 2023, 7:27pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/1 "2023-01-27T19:27:38Z")

</div>

**Your software**  
My Mautic version is: 3.2.4 upgrading to 4.4.5  
My PHP version is:7.4.9  
My Database type and version is: MySQL 5.7.31

My problem is:  
Upgrading from 3.2.4 to 4.4.5 seems to go fine and says that the upgrade has completed successfully, however, when I check to see if there are outstanding queries to bring the update up to date using console doctrine:schema:update --dump-sql, I see the following:

DROP INDEX IDX\_1AE3441319EB6921 ON oauth2\_user\_client\_xref

- DROP INDEX IDX\_6480052EF639F774 ON campaign\_leadlist\_xref
- DROP INDEX IDX\_3048A8B2F639F774 ON campaign\_form\_xref
- DROP INDEX IDX\_5995213DF639F774 ON campaign\_leads
- DROP INDEX IDX\_2E24F01CA832C1C9 ON email\_list\_xref
- DROP INDEX IDX\_CA315778A832C1C9 ON email\_assets\_xref
- ALTER TABLE form\_fields CHANGE parent\_id parent\_id VARCHAR(191) DEFAULT NULL
- ALTER TABLE lead\_fields CHANGE column\_is\_not\_created column\_is\_not\_created TINYINT(1) DEFAULT ‘0’ NOT NULL, CHANGE original\_is\_published\_value original\_is\_published\_value TINYINT(1) DEFAULT ‘0’ NOT NULL
- DROP INDEX googleplus\_search ON leads
- DROP INDEX address2\_search ON leads
- DROP INDEX state\_search ON leads
- DROP INDEX country\_search ON leads
- DROP INDEX timezone\_search ON leads
- DROP INDEX address1\_search ON leads
- DROP INDEX city\_search ON leads
- DROP INDEX zipcode\_search ON leads
- ALTER TABLE leads DROP googleplus, CHANGE fax fax VARCHAR(191) DEFAULT NULL, CHANGE preferred\_locale preferred\_locale VARCHAR(191) DEFAULT NULL, CHANGE website website VARCHAR(191) DEFAULT NULL, CHANGE facebook facebook VARCHAR(191) DEFAULT NULL, CHANGE foursquare foursquare VARCHAR(191) DEFAULT NULL, CHANGE instagram instagram VARCHAR(191) DEFAULT NULL, CHANGE linkedin linkedin VARCHAR(191) DEFAULT NULL, CHANGE skype skype VARCHAR(191) DEFAULT NULL, CHANGE twitter twitter VARCHAR(191) DEFAULT NULL, CHANGE fromfirst fromfirst VARCHAR(191) DEFAULT NULL, CHANGE fromlast fromlast VARCHAR(191) DEFAULT NULL, CHANGE iqfromtext iqfromtext VARCHAR(191) DEFAULT NULL, CHANGE jobtitle jobtitle VARCHAR(191) DEFAULT NULL, CHANGE businessline businessline VARCHAR(191) DEFAULT NULL, CHANGE owneralias owneralias VARCHAR(191) DEFAULT NULL, CHANGE ownerfullname ownerfullname VARCHAR(191) DEFAULT NULL, CHANGE eventname eventname VARCHAR(191) DEFAULT NULL, CHANGE eventdate eventdate VARCHAR(191) DEFAULT NULL, CHANGE awardyears awardyears VARCHAR(191) DEFAULT NULL, CHANGE awardvalue awardvalue VARCHAR(191) DEFAULT NULL, CHANGE garvyaward garvyaward VARCHAR(191) DEFAULT NULL, CHANGE teamname teamname VARCHAR(191) DEFAULT NULL, CHANGE ownertitle ownertitle VARCHAR(191) DEFAULT NULL, CHANGE school school VARCHAR(191) DEFAULT NULL
- CREATE INDEX website\_search ON leads (website)
- DROP INDEX IDX\_9EED7E6655458D ON lead\_ips\_xref
- DROP INDEX IDX\_F2E51EB655458D ON lead\_tags\_xref
- DROP INDEX IDX\_F5F47C7CB9FC8874 ON lead\_lists\_leads
- DROP INDEX companycity\_search ON companies
- DROP INDEX companyzipcode\_search ON companies
- DROP INDEX companyname\_search ON companies
- DROP INDEX business\_line\_search ON companies
- DROP INDEX companyaddress1\_search ON companies
- DROP INDEX companyindustry\_search ON companies
- DROP INDEX companyemail\_search ON companies
- DROP INDEX companyphone\_search ON companies
- DROP INDEX companystate\_search ON companies
- DROP INDEX companycountry\_search ON companies
- DROP INDEX organization\_search ON companies
- DROP INDEX companyaddress2\_search ON companies
- ALTER TABLE companies DROP organization, DROP business\_line, CHANGE companywebsite companywebsite VARCHAR(191) DEFAULT NULL, CHANGE companyfax companyfax VARCHAR(191) DEFAULT NULL
- DROP INDEX IDX\_F4190AB6979B1AD6 ON companies\_leads
- ALTER TABLE push\_notifications CHANGE name name VARCHAR(191) NOT NULL, CHANGE heading heading LONGTEXT NOT NULL, CHANGE message message LONGTEXT NOT NULL
- DROP INDEX IDX\_473919EFEF1A9D84 ON push\_notification\_list\_xref
- CREATE INDEX page\_hit\_url ON page\_hits (url(128))
- DROP INDEX IDX\_2F81A41DB42D874D ON channel\_url\_trackables
- DROP INDEX IDX\_6DF94A56C028CEA2 ON point\_lead\_action\_log
- DROP INDEX IDX\_C2A3BDBA71F7E88B ON point\_lead\_event\_log
- DROP INDEX IDX\_B032FC2EBD5C7E60 ON sms\_message\_list\_xref
- DROP INDEX IDX\_A506AFBE2298D193 ON stage\_lead\_action\_log
- DROP INDEX webhook\_id\_date ON webhook\_queue
- DROP INDEX IDX\_45207A4A4CE1C902 ON monitoring\_leads

if I try force those updates using php console doctrine:schema:update --force, I am getting the following errors:

In AbstractMySQLDriver.php line 128:  
An exception occurred while executing ‘DROP INDEX IDX\_1AE3441319EB6921 ON oauth2\_user\_client\_xref’:

SQLSTATE[42000]: Syntax error or access violation: 1091 Can’t DROP ‘IDX\_1AE3441319EB6921’; check that column/key exists

In Exception.php line 18:  
SQLSTATE[42000]: Syntax error or access violation: 1091 Can’t DROP ‘IDX\_1AE3441319EB6921’; check that column/key exists

In PDOConnection.php line 141:  
SQLSTATE[42000]: Syntax error or access violation: 1091 Can’t DROP ‘IDX\_1AE3441319EB6921’; check that column/key exists

Any thoughts on what I should be doing or how is should make sure the schema is up to date. I’m reluctant to make this upgrade live if it may be unstable.

Thanks in advance for any help you can offer.

---

<div class="post-metadata">

**Author:** ![joeyk](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/joeyk/32/11164_2.png) [@joeyk](https://forum.mautic.org/u/joeyk)\
**Post date:** [January 29, 2023, 9:06am UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/2 "2023-01-29T09:06:50Z")

</div>

I have seen this a lot. It happens, because client\_id in the oauth2\_user\_client\_xref table is different format then in the id in the oauth\_client table. Somewhere the 2 values got messed up, one is 10 the other one 11 long. I usually use some dirty thricks to overcome this issue, I would love to see an elegant long lasting solution. @escopecz ?  
This migration is between Mautic 2.16.5 and M3.

---

<div class="post-metadata">

**Author:** ![sgtbhaji](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/sgtbhaji/32/637_2.png) [@sgtbhaji](https://forum.mautic.org/u/sgtbhaji)\
**Post date:** [February 1, 2023, 2:28pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/3 "2023-02-01T14:28:32Z")

</div>

Thanks for the reply. Any tips on those dirty tricks? Just want to be sure everything is updated completely before switching over to the 4.4.5. Thanks!

---

<div class="post-metadata">

**Author:** ![joeyk](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/joeyk/32/11164_2.png) [@joeyk](https://forum.mautic.org/u/joeyk)\
**Post date:** [February 2, 2023, 7:23am UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/4 "2023-02-02T07:23:31Z")

</div>

Hi, again: I’m not sure it’s the right way to do it, but what I did is synched the field lenght so the error for the oauth2 tables would disappear. After that it ran properly for me.  
Not sure if this is the right way.

---

<div class="post-metadata">

**Author:** ![joeyk](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/joeyk/32/11164_2.png) [@joeyk](https://forum.mautic.org/u/joeyk)\
**Post date:** [February 2, 2023, 7:24am UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/5 "2023-02-02T07:24:15Z")

</div>

Do you get the error, that that Index doesn’t exists?

---

<div class="post-metadata">

**Author:** ![plato39](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/plato39/32/2343_2.png) [@plato39](https://forum.mautic.org/u/plato39)\
**Post date:** [February 3, 2023, 4:57pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/6 "2023-02-03T16:57:59Z")

</div>

I am also seeing this on trying to upgrade. I actually tested a fresh install of 4.4.5 and 4.4.6 and even fresh installs have the same issue.

In AbstractMySQLDriver.php line 128:

An exception occurred while executing ‘DROP INDEX IDX\_DED9EA1819EB6921 ON m  
auea\_oauth2\_user\_client\_xref’:

Can’t DROP INDEX `IDX_DED9EA1819EB6921`; check that it exists

In StatementError.php line 21:

Can’t DROP INDEX `IDX_DED9EA1819EB6921`; check that it exists

---

<div class="post-metadata">

**Author:** ![plato39](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/plato39/32/2343_2.png) [@plato39](https://forum.mautic.org/u/plato39)\
**Post date:** [February 4, 2023, 2:18pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/7 "2023-02-04T14:18:34Z")

</div>

I have seen the exact same outstanding queries report when running Mautic updates from 4.3.0 onwards. I tested this on a local install last night. Although the updates always complete - all migrations are completed - the same outstanding queries are listed when running:

console doctrine:schema:update --dump-sql

Can we therefore assume that it is the schema report mechanism that is buggy and that the Mautic upgrades have completed successfully? Running the queries manually through phpMyAdmin proves that the queries reported are false.

If this is the case then can we please acknowledge this bug so people are not wasting their time trying to fix a non-existent fault with their database every time they update?

---

<div class="post-metadata">

**Author:** ![fkrafft](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/fkrafft/32/2220_2.png) [@fkrafft](https://forum.mautic.org/u/fkrafft)\
**Post date:** [January 19, 2025, 10:55pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/8 "2025-01-19T22:55:44Z")

</div>

Any update on the “right way” to handle these table references?

And FYI, I have similar problem on a 4.4.13.  
I checked that the  
_client\_id_ in _oauth2\_user\_client\_xref_ matched  
the _id_ in _oauth2\_clients._

And they are of the same type and length.

DESCRIBE oauth2\_clients;  
±--------------------±-----------------±-----±----±--------±---------------+  
| Field | Type | Null | Key | Default | Extra |  
±--------------------±-----------------±-----±----±--------±---------------+  
| id | int(10) unsigned | NO | PRI | NULL | auto\_increment |

DESCRIBE oauth2\_user\_client\_xref;  
±----------±-----------------±-----±----±--------±------+  
| Field | Type | Null | Key | Default | Extra |  
±----------±-----------------±-----±----±--------±------+  
| client\_id | int(10) unsigned | NO | PRI | NULL | |

---

<div class="post-metadata">

**Author:** ![fkrafft](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/fkrafft/32/2220_2.png) [@fkrafft](https://forum.mautic.org/u/fkrafft)\
**Post date:** [January 19, 2025, 11:15pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/9 "2025-01-19T23:15:00Z")

</div>

Continued:

Assume the out of sync mapping is related to my issue:

**Command:**  
php bin/console doctrine:schema:validate

## **Output:** Mapping

[FAIL] The entity-class Mautic\DynamicContentBundle\Entity\DynamicContentLeadData mapping is invalid:

- The association Mautic\DynamicContentBundle\Entity\DynamicContentLeadData#dynamicContent refers to the inverse side field Mautic\DynamicContentBundle\Entity\DynamicContent#id which is not defined as association.
- The association Mautic\DynamicContentBundle\Entity\DynamicContentLeadData#dynamicContent refers to the inverse side field Mautic\DynamicContentBundle\Entity\DynamicContent#id which does not exist.

## Database

[ERROR] The database schema is not in sync with the current mapping file.

---

<div class="post-metadata">

**Author:** ![diamondtheta](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.mautic.org/diamondtheta/32/14396_2.png) [@diamondtheta](https://forum.mautic.org/u/diamondtheta)\
**Post date:** [September 6, 2025, 12:12pm UTC](https://forum.mautic.org/t/outstanding-queries-after-upgrade-to-4-4-5/26884/10 "2025-09-06T12:12:29Z")

</div>

I had same “can’t drop index” errors and my “mautic expert” hosting company aslo could NOT solve it.. even with all ChatGPT + Claude AI help, and i also did all commands as they told and searched all forums, etc. and the “can’t drop index” came up even after full composer install, and even on full empty and new database on mautic 6.0.5 with very new almost 100% compozer fresh install also. So please solve that because it seems that bug is comiing up again and again in different forms (indexes) with every upgrade when someone migrated through from an earlier non compozer mautic.. ☹ (for chema update)

And that problem also for doctrine:schema:validate:

”Mapping

[FAIL] The entity-class Mautic\DynamicContentBundle\Entity\DynamicContentLeadData mapping is invalid:

- The association Mautic\DynamicContentBundle\Entity\DynamicContentLeadData#dynamicContent refers to the inverse side field Mautic\DynamicContentBundle\Entity\DynamicContent#id which is not defined as association.

“  
So and if I delete the indexes manually from SQL it creates them again, or want to delete again, and if it needs them because cannot delete but wants to delete, and i create them for doctrine to be able to delete the index it says it cannot create because it is duplicate or similar … so every time i do manually in SQL what it want to do it wants then to do the opposite, or drags in a loop, like the primary key deleting or ignoring globally also do NOT solves it, and it is a NIGHTMARE!

SO it is SURELY not “just a single migration file” or SURELY NOT “just an update or just some version specific error” it is a HUGE core BUG, maybe in doctrine itself i think now… so maybe not just mautic specific, and i saw this came up again and again since mautic 2 to mautic 6 , with my 6.0.5 also, so it is surely not just “1 bad written files” for some “bad indexes” but the whole index generating mechanism itself, or the core of the whole index generating / checking algoritm i am now sure of this!!! so please ask the doctrine developers themselfes also to fix that, because this was also not just on mautic forums! the “can’t drop index” error!!! Thanks! :))
