“Form already exists” error when updating XML form version (some version numbers work, some don’t)

Support
1

Hi all,

I’m seeing strange behavior when trying to update a form by changing only the version. I’ve read the documentation and some forum posts about form updates and versioning, but I haven’t found this exact case yet.

Environment

  • Server:ODK Aggregate

  • Form is designed as XLSForm and converted to XML

    What I’m doing

  • I have one form with a fixed form_id.

  • I am not changing the form structure (no new questions, no removed questions, no type changes).

  • I only change the version value in the XLSForm and upload the new XML to the server.

Unexpected behavior

  • Version numbers 1 through 9 upload successfully.

  • When I try version numbers 10, 11, 12, …, 41, the server shows a “form already exists”–type error and does not accept the form.

  • If I then change the version to 90, the form uploads successfully.

  • Versions 91 and 92 also upload successfully.

So some numeric versions (10–41) are rejected, while others (1–9, 90+) are accepted, even though I am only changing the version and keeping the form structure the same.

Questions for the community

  1. Has anyone seen a situation where only a specific range of version numbers (like 10–41) is rejected with a “form already exists” error, while other version numbers for the same form are accepted?

  2. Is there any known behavior in Aggregate that could cause certain version values to conflict internally, even when the form structure is unchanged?

  3. Do you recommend a particular **versioning pattern
    **
    Any technical explanation, known bug reference, or best‑practice advice on safe versioning for XML forms would be very helpful.

    Thanks in advance!

2

I strongly recommend that you stop using Aggregate and switch to Central. Aggregate has not been updated in over 6.5 years, and it is no longer supported or secure. You are also missing out on many bug fixes and new features.

As for your question, we recommend using a format like yyyymmddrr for versions. For example, 2017021505 represents the fifth revision from February 15, 2017.

2 Likes
3

The problem is that Aggregate requires version values that are later when sorted alphabetically. Later versions of Aggregate have a more helpful error message:

Form versions are sorted alphabetically. For example, version 10 sorts before version 2 because the left-most character is used to sort. Please update the form version and resubmit.

We recommend using 10-digit version numbers that use the current date and a count. For example, for the second form on May 5th, 2024, use 2024050502

2 Likes