Migration fails: migration renumbers documents in database

0
While migrating from 2.5.3hotfix to 2.5.8 to 3.3.5 to 4.4.2 the uploaded files (FileDocument) seem to be re-numbered in the database. If you try to open a document after migration, you get another document. Scenario: During the past years files were uploaded in the 2.5.3hotfix version of the Mendix app. Migrated Mendix app from 2.5.3hotfix to 2.5.8 to 3.3.5 to 4.4.2 After starting the migrated app, the uploaded files (FileDocument) seem to be re-numbered in the database. If you try to download a document after migration, you get another document. Is this a common issue? Please let me know how I could solve this issue :) . Thanks!
asked
2 answers
2

Thanks for the response :) . Got the following answer from Mendix support:

When you start a Mendix app on a new model, Mendix offers a list of database synchronization commands, reflecting the model changes. It is possible to execute these commands as DBA manually on the database. When you restart the app, Mendix recognizes the already up-to-date state of the database and completes the start process of the app. However, if you do a migration to Mendix 4, it is not possible to plainly execute the database synchronization commands manually. Part of the migration is a rename of the uploaded file documents and images. Before Mendix 4, file documents have their database ID as name. Since Mendix 4, file documents have their FileID as name, so some or all names have to be changed as part of the migration process. This renaming part is coupled to the database synchronization state. If you execute the database synchronization commands manually, Mendix assumes the file names are also already be renamed. Mendix will not do the rename of the files anymore and as a result, the wrong files will be coupled to the file documents in the database!

In order to still be able to execute the commands manually, please remove the last two commands (with UPDATE "mendixsystem$version") from the database script:

Remove: UPDATE "mendixsystem$version" SET "versionnumber" = '4.0.5', "lastsyncdate" = '20130415 13:37:32';

UPDATE "mendixsystem$version" SET "versionnumber" = '4.0.6', "lastsyncdate" = '20130415 13:37:32';

Now the last command will be and has to be (!): UPDATE "mendixsystem$version" SET "versionnumber" = '4.0.4', "lastsyncdate" = '20130415 13:37:32';

After you have executed the remaining commands manually, you can restart your app. Mendix asks you to execute the two removed commands. Please do not execute these commands manually (!), but let Mendix execute them. Now Mendix will still do the file documents renaming step of the migration process.

In Mendix 4.5, we will separate the database synchronization phase from the file rename phase of the migration process. It is then possible to safely execute all database synchronization commands manually on the database, without changing anything.

I will try if this solves the problem. If it doesn't work I will post an example project :) .

answered
0

It's not a common issue, please submit your project, the original 2.5.3 database and the files in the ticket. Which hotfix version is this you were running on?

(If the data is sensitive then you can do with just the tables for System.FileDocument and all inheriting entities. For the files themselves you could replace the content by the text of how the file is named currently, i.e. '253' for file '253' so we can still recognize the files)

answered