An error occurred while executing action Execute DDL commands

1
Good morning, We recently upgraded an application we inherited and are running into some issues. Namely that we cannot start the application anymore on-premise. Locally, this runs fine.  Since we inherited the application, we noticed that some app store modules have never been upgraded by our predecessors or are very outdated, at least. To perform a neat upgrade, we attempted to upgrade all modules and clean up the userlib. However, when we try to start the application in our test environment after doing all that, we receive the following error and the startup is terminated: An error occurred while executing action 'Execute DDL commands'. -------- com.mendix.m2ee.api.AdminException: Executing DDL commands failed. at com.mendix.basis.component.internal.LocalComponentImpl.executeDDLCommands(LocalComponentImpl.scala:115) Caused by: com.mendix.basis.connectionbus.ConnectionBusException: Error (SQL State: S0007, Error Code: 3701) on executing: DROP INDEX [idx_mxmodelreflection$token_combinedtoken] ON [mxmodelreflection$token] All changes are rolled back. at com.mendix.connectionbus.modelsynchronization.DdlCommandExecutor.execute(DdlCommandExecutor.java:79) Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Cannot drop the index 'mxmodelreflection$token.idx_mxmodelreflection$token_combinedtoken', because it does not exist or you do not have permission. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:254) at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1608) at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:859) at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:759) at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7240) at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2869) at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:243) at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:218) at com.microsoft.sqlserver.jdbc.SQLServerStatement.execute(SQLServerStatement.java:739) at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291) at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291) at com.mendix.connectionbus.modelsynchronization.DdlCommandExecutor.executeDdlCommands(DdlCommandExecutor.java:136) at com.mendix.connectionbus.modelsynchronization.DdlCommandExecutor.execute(DdlCommandExecutor.java:43) at com.mendix.connectionbus.modelsynchronization.SynchronizationManager.synchronizeModel(SynchronizationManager.scala:170) at com.mendix.connectionbus.modelsynchronization.SynchronizationManager.executeImpl(SynchronizationManager.scala:161) at com.mendix.connectionbus.modelsynchronization.SynchronizationManager.execute(SynchronizationManager.scala:108) at com.mendix.connectionbus.ConnectionBusImpl.executeDDLCommands(ConnectionBusImpl.java:392) at com.mendix.basis.component.internal.LocalComponentImpl.executeDDLCommands(LocalComponentImpl.scala:107) at com.mendix.basis.impl.MxRuntimeImpl.executeDDLCommands(MxRuntimeImpl.java:1009) at com.mendix.basis.action.admin.ExecuteDDLCommandsAction.call(ExecuteDDLCommandsAction.java:26) at com.mendix.basis.action.admin.RuntimeAdminAction.execute(RuntimeAdminAction.java:18) at com.mendix.m2ee.appcontainer.server.handler.HttpAdminHandler.handle(HttpAdminHandler.java:129) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:502) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) at java.lang.Thread.run(Unknown Source) Can anyone point us in the direction of what this means and how we can resolve this?  We attempted to downgrade the MxModelReflection but cannot do so, as we've already upgraded our project.  Your input is very welcome!  Regards, Laxmi  
asked
2 answers
1

Each time you run your project or restart after deployment, Mendix will try to make sure that the tables in the database match the domain models in your project. For this purpose Mendix tries to keep track of the changes and execute the necessary SQL statements to alter the database on startup.

For some reason Mendix is confused, and is looking for an association that it can no longer find. Try to see if you renamed modules and associations in the process of upgrading of possibly deleted some association and try to rename them back to the old values. Then try to restart and if that succeeds perform the renaming again. 

answered
0

Do you have a (earlier) database backup of the test environment? It is possible to spend a lot of time in fixing the test database, but it might be easier to take a fresh backup and see if that works.

If possible and allowed, the best option would be to restore a production database and start it against that one (since you will be upgrading the production server at a later moment and don’t want to run into issues there)

Another cause for the issue could be that a database was restored, but some permissions are missing. Mendix uses a specific database user/password combination to log on to the database, and possibly for a SQL server database the database admin needs to grant certain roles to the account that Mendix uses in order to access the database (and perform DDL commands) .

 

For example: you have a database named ‘Mendix’ and a user called “Mx_Login”. After restoration the “Mx_Login”  user might need to be re-mapped to the database and receive the proper permissions (for example db_owner). Also the default schema should be the same as the schema that the database is imported into, but a DBA should be able to assist you further on this

 

answered