How to Retrieve Mendix File Documents Stored in MSSQL Without Using Mendix

0
Hi,We have a Mendix application where documents and other records are stored in an MSSQL database. We need to migrate all data, including uploaded documents, to another application that will not use Mendix.Can anyone guide us on:How Mendix stores FileDocument data in MSSQL?How to retrieve document files along with their associated business records?What is the best approach to migrate these documents to another database without using the Mendix Runtime?Any documentation or sample SQL queries would be very helpful.Thanks!
asked
2 answers
0

Hi Pankaj,

Yes, it is possible to migrate the documents without using Mendix Runtime, but I would not recommend directly reading the Mendix database tables and extracting the binary data unless you fully understand the database structure.


A System.FileDocument is the Mendix system entity used for storing files, and its file content is binary data. Mendix also supports binary attributes directly in the database, although for most file scenarios Mendix recommends using a FileDocument association.


For a migration, I would suggest this approach:

  1. Identify the business entity → FileDocument association in your domain model.
  2. Retrieve the corresponding FileDocument records, including metadata such as:
    • File name
    • MIME type
    • Size
    • Creation date
    • Object ID
  3. Extract the actual binary content.
  4. Store the binary files in the target application's file storage.
  5. Keep the original Mendix object ID/association information as a migration reference so you can map the documents back to the correct business records.


If you still have access to the Mendix application, a safer migration approach is to expose/retrieve the files through Mendix rather than querying the internal database directly. Mendix supports retrieving FileDocument content through REST and storing the binary response as a file.


Also, depending on the deployment architecture, don't assume that the document binary is necessarily stored in the MSSQL database. For example, current Mendix environments can use separate blob/file storage for System.FileDocument contents.


So before writing SQL queries, Expose as REST API and Use in Non Mendix Application.


Kindly mark this as the accepted answer if it helps.


answered
0

Hi Pankaj,


One important point here is that the FileDocument metadata and the actual file content are not necessarily stored in the same place.


For a normal Mendix System.FileDocument (or a specialization of it), the FileDocument object and its metadata are stored in the relational database, but the actual binary file content is managed by Mendix's File Storage. Mendix documents this separately from the relational database storage.


So if your application is using System.FileDocument, querying the MSSQL database alone will generally not give you the actual PDF/Word/image contents.


The migration needs to consider two parts:

MSSQL
 ├── FileDocument metadata
 ├── Business records
 └── Associations between them

File Storage
 └── Actual file contents
      ├── PDF
      ├── DOCX
      ├── Images
      └── etc.

The association between your business entity and the FileDocument is stored in the Mendix database, so that association is what you use to map a document back to its business record.

For example:

Customer
   |
   +-- Document (FileDocument)
          |
          +-- Invoice.pdf

If the target application is not Mendix

I would not recommend copying the Mendix database tables directly into the target application.

Instead, migrate the data as two related datasets:

  1. Export the business data and the required FileDocument metadata from MSSQL.
  2. Export/copy the corresponding files from the Mendix File Storage.
  3. Use the Mendix object identifiers/associations as the mapping between the business record and the physical file.
  4. Load the business records and files into the target application's own data model/storage.

For example, create a migration mapping such as:

Mendix Document ID
Business Record ID
File Name
File Size
Content Type
Storage File

and use the Mendix Document ID as the temporary migration key.


About doing this completely without the Mendix Runtime

It is possible to perform a migration without calling Mendix microflows, provided you have direct access to both the MSSQL database and the underlying file storage.


However, I would avoid relying on undocumented Mendix internal tables or constructing file paths from database IDs. The exact storage implementation can depend on the deployment/storage configuration, and those internal details are not a supported external integration contract.


For example, in a containerized/private-cloud setup, Mendix can use external blob storage such as S3, Azure Blob Storage, MinIO, or other supported storage options, rather than storing the files in MSSQL.


If this is a database-to-database migration between Mendix applications, there is also another important consideration: Mendix states that you cannot simply copy data from one Mendix app's database to another because entity identifiers are app-specific. For that scenario, Mendix recommends using the Database Replication module rather than copying the tables directly.


So the first thing I would establish is where the current environment stores its FileDocument contents. Once that is known, the migration can be designed as:

MSSQL
  ↓
Export business data + FileDocument metadata
  ↓
Preserve Document ID / association mapping
  ↓
Export files from Mendix File Storage
  ↓
Transform
  ↓
Target application's DB + file storage

I would not rely on a SQL query against the MSSQL database alone to retrieve the actual FileDocument binary content unless the application is specifically using a Binary attribute instead of System.FileDocument. Mendix documents Binary attributes as being stored in the database, whereas FileDocument content is handled through file storage.


Hope this helps.

answered