<-- Back

How to use MPRtool to determine if data loss after deployement is due to a recreated database entity

Introduction

This article explains how to determine whether data loss in a Mendix app occurred because a database entity table was dropped and recreated. When an entity's Data Storage Globally Unique Identifier (GUID) changes, the Mendix runtime treats it as a new entity, drops the existing database table, and recreates it — resulting in the loss of all data in that table.

Use MPRtool to compare the entity GUIDs between the MPR file from before deployment and the MPR file from after deployment. If the Data Storage GUID of the affected entity differs between the two files, the runtime treated it as a new entity, dropped the old table, and recreated it — confirming data loss due to entity recreation.

Environment

Studio Pro (All versions)

Instructions/Procedure

Follow the steps below to compare the entity GUIDs between two MPR files and determine whether a GUID change caused the data loss.

  • Open MPRtool. The default installation path is: C:\Program Files\Mendix\<version>\modeler\MprTool.exe. Replace <version> with the installed Mendix Studio Pro version.
  • Open both .mpr files in MPRtool
  • Locate the affected entity and check its GUID value (the Data Storage GUID).
  • Compare the two GUID values

 

Please note ach entity in a Mendix model has two GUIDs:

  • Model GUID ($ID in MPRtool): uniquely identifies the entity in the model. The merge algorithm uses this identifier to recognize objects even after they are renamed.
  • Data Storage GUID (GUID in MPRtool): used to synchronize the database with the domain model. This value is stored in mendixsystem$entity.id and is the only identifier the runtime uses to map an entity to its database table.

During deployment, the runtime compares the entity Data Storage GUIDs in the model against the records in mendixsystem$entity. If a GUID is new, the runtime creates a new table. Therefore, if the Data Storage GUID of an entity changes between deployments, the runtime drops the old table and creates a new one, deleting all existing data.

Outcome

After completing these steps, it is confirmed whether a change in the entity Data Storage GUID between deployments caused the runtime to drop and recreate the database table, resulting in data loss.

Internal information related

  • 120845, 278570
  • C0A5EDRD2/p1656513447177109, C0A5EDRD2/p1647588916043539

Additional information

Related KBA: Data loss after deployment due to recreated domain model entities

Have more questions? Submit a request

0 Comments

Article is closed for comments.

To provide feedback, please open a ticket here. Don't forget to include the article's URL along with the feedback you would like to provide.