Three uploaders use same entity ?

Hi Kaustubh,

I was able to reproduce a similar scenario and wanted to share how I implemented the File Uploader setup.

In my case, I used a simple LeaveRequestForm entity and a single DocumentProof entity inheriting from System.FileDocument. Instead of creating separate file entities for each uploader, I used two different associations between the same entities to differentiate the files uploaded through each uploader.

Domain model

I created the following associations:

• DocumentProof_LeaveRequestForm — used by File Uploader 1
• DocumentProof_Proof — used by File Uploader 2

So, both uploaders use the same DocumentProof entity, but the relationship through which the file is associated with the LeaveRequestForm is different.

File Uploader 1

For the first uploader, I configured the Associated files as:

[DocumentProof, over association 'DocumentProof_LeaveRequestForm']

I also configured a dedicated nanoflow:

ACT_CreateUploadedFileDocument

This nanoflow creates the DocumentProof object and associates it with the LeaveRequestForm through DocumentProof_LeaveRequestForm.

File Uploader 2

For the second uploader, I configured:

[DocumentProof, over association 'DocumentProof_Proof']

And used a separate nanoflow:

ACT_CreateUploadedFileDocument_Proof

This creates another DocumentProof object but associates it through DocumentProof_Proof.

Why I used this approach

The important point here is that I am not creating a separate entity for each uploader. Both uploaders use the same DocumentProof entity. The files are differentiated based on the association through which they are linked to the parent LeaveRequestForm.

This allows me to have multiple uploaders on the same page while maintaining a clear separation between the files uploaded by each uploader.

I have also attached the relevant domain model and file uploader configurations for reference.

With this setup, I was able to upload multiple files through both uploaders successfully.

I hope this will help. One more thing: kindly check whether the child object is getting auto-committed when the file is uploaded.

If the issue persists, kindly share a screenshot of the implementation process.

Hi,

Yes, this looks more like a File Uploader configuration/concurrency issue than a database problem itself.

The system$filedocument_pkey error means Mendix is trying to persist two System.FileDocument objects with the same object ID. Since the failure happens mainly when multiple File Uploader instances are uploading files at the same time, I would first check how the uploaders create and associate their FileDocument objects.

The File Uploader documentation recommends that each uploader has a correctly configured Associated files entity and corresponding create-new-file nanoflow.

I would avoid adding waits or changing max-concurrent uploads as the primary fix. Those may hide the race condition rather than fixing the object creation.

A setup that works well for multiple uploaders is to use the same System.FileDocument specialization but separate associations for each uploader. For example:

LeaveRequest
   |
   +-- DocumentProof_Invoice --> DocumentProof
   |
   +-- DocumentProof_Contract --> DocumentProof

DocumentProof
   |
   +-- generalization: System.FileDocument

Then configure:

Uploader 1

Associated files:
DocumentProof over DocumentProof_Invoice

Action to create new files:
ACT_CreateUploadedFileDocument_Invoice

Uploader 2

Associated files:
DocumentProof over DocumentProof_Contract

Action to create new files:
ACT_CreateUploadedFileDocument_Contract

Each nanoflow should create a new DocumentProof object, set the appropriate association to the current context object, and then return/use that object for the upload.

This approach has also been reproduced in the Mendix Community for this exact question: two uploaders used the same System.FileDocument specialization with different associations and separate create nanoflows, and multiple files could then be uploaded through both uploaders successfully.

I would also check one important thing in your current implementation:

• Don't let both uploaders point to the same already-created FileDocument object.
• Don't reuse a FileDocument object variable between the two upload flows.
• Make sure the create nanoflow actually executes Create object for every uploaded file.
• Check whether the FileDocument is being committed automatically and then committed again by your own microflow/nanoflow logic.
• If you have custom logic after upload, temporarily remove it and test the standard File Uploader configuration first.

The fact that you already tried a wait, a microflow, an error handler, and max-concurrent upload = 1 is useful: I wouldn't continue tuning concurrency until the object/association configuration is verified.

Also, File Uploader 2.5.0 is listed as compatible with Mendix 10.22+ and its release notes don't mention a fix for this particular primary-key collision, so I wouldn't assume that 10.24.18 itself is the root cause.