Mx 8.19 --> Mx 9.6 upgrade error

Hi, I recently upgraded our free app from Mendix 8.19 → 9.6 (current MTS version). However with the transition it seems like we’re having some strange issues. For some reason ListViews with a specific entity in our app don’t load anymore.  The app runs fine locally, but the issue happens when deploying to the sandbox. When trying to load the page in the sandbox with the list view we get the following error: Connector: com.mendix.webui.WebUIException: Exception while retrieving data for 'Core.Model_Overview.listView1' on document 'Core.Model_Overview' … few lines of stacktrace later: Caused by: com.mendix.core.CoreRuntimeException: The provided entity id '18' has no corresponding meta object name ^ anyone have an idea what this error means? The strange thing is that on the same page, I can load the same object just fine in a datagrid… I’ve seen a few posts with the same error message: * * * * * * All of which are relatively unhelpful. They do insinuate that something went wrong most likely when synchronizing databases between different deployed versions? But I’m not entirely sure how to fix it...
4 answers

Small addition that I noticed as I’m trying out different things to identify a fix. I’m also noticing that each time I deploy a small change the Build fails. The Build Output from the dev portal unfortunately doesn’t tell me much (seems to only show a partial log):

But if I click “Publish” a second time after the failure from Studio Pro it seems to build. But that might also be a hint towards what’s going wrong?


Well the build failures seem to be unrelated, I recently saw this in the runtime logs when triggering a “Publish”: 

Failed to stage build: insufficient resources: memory

So most likely that’s just due to a lack of memory on the running node.

Still no closer to solving my issue, but the weird thing I have found is that I am able to load a ListView with some of the entity data if I use an older microflow that was also returning this entity. The strange thing is that if I copy that exact microflow in a new microflow, it doesn’t work...

I’m pretty dumbfounded. This just seems like a very strange bug.


I’ve been able to export the backup and examine the mendixsystem$entityidentifier and mendixsystem$entity data. There is no object with entity ID 18. The entity actually has the ID 30.

I also

I also wrote a simple java action that pulls the short ID of an object:

import com.mendix.systemwideinterfaces.core.IContext;
import com.mendix.webui.CustomJavaAction;
import com.mendix.systemwideinterfaces.core.IMendixObject;
import com.mendix.systemwideinterfaces.core.meta.IMetaObject;

public class GetMetaObjectShortId extends CustomJavaAction<java.lang.Long>
	private IMendixObject ObjectToGetShortId;

	public GetMetaObjectShortId(IContext context, IMendixObject ObjectToGetShortId)
		this.ObjectToGetShortId = ObjectToGetShortId;

	public java.lang.Long executeAction() throws Exception
		IMetaObject MetaObject = this.ObjectToGetShortId.getMetaObject();
		long ShortToReturn = (long)MetaObject.getId();

		return ShortToReturn;

	 * Returns a string representation of this action
	public java.lang.String toString()
		return "GetMetaObjectShortId";


I’ve used this in the retrieve microflow that works for loading the entity in ListViews. It returns the ShortId 30, which in the backup that I pulled corresponds to the correct entity.

So why is it that ListViews are trying to execute an XPath query to an entity with the ID 18?


For anyone reading this and dealing with the same issue. Unfortunately I was not able to fix it. I did figure out a little more that it was most likely the same thing that Thijs was facing in his forum post here:

I saw in the underlying data that there were objects that had different short-ids. Which I couldn’t really figure out how to fix. At first I tried deleting the objects with the ‘missing’ id. Which fixed my issue for loading data in the List Views. But I later had issues with editing new objects of the same entity, with the same error message, which leads me to believe that the mixed ID was also still being used somewhere else. 

Instead of spending more time on this bug I decided it was best to unlink my sandbox and start with a fresh database.

Unfortunate that a major version upgrade leads to issues like this, but not entirely sure what I could have done to prevent it or resolve the issue.