Select to view content in your preferred language

Branch version changes not in default after posting

189
4
a week ago
malte
by
Occasional Contributor

Hello,

we are having the following issue with branch versioning:

After adds, updates and deletes are made, we reconcile and post to the default version. In some cases, the edits made to one or multiple that were edited do not appear in the default version. They also disappear from the version changes, so when we click on Version Changes in ArcGIS Pro, there are no changes listed. One way to make the changes appear again in the Version Changes is to edit the attribute of one of the features in the affected layer. Posting again after doing that, it mostly works and the changes appear in the default version.

I looked into our postgresql database and checked what happened when this issue appeared. I saw that in the table sde_branch_tables_modified, all rows with the branch_id of the affected version disappear after posting (which I think is the expected behaviour), but the edited features in the table keep the gdb_branch_id of the version instead of switching to 0 (default version). It's hard to properly analyze the problem though, as it does not happen constantly or in any recognizable pattern. I also can't find any relevant entries in the logfiles.

Any advice or similar experiences?

Best regards

Tags (1)
4 Replies
malte
by
Occasional Contributor

I found this error in our Postgresql logs:

2025-09-29 09:02:47.604 CEST [7128] ERROR: duplicate key value violates unique constraint "uuid_18"
2025-09-29 09:02:47.604 CEST [7128] DETAIL: Key (globalid, gdb_branch_id, gdb_from_date)=({4F4A5238-CE0F-43A9-BA72-ABCFE92F655F}, 0, 2025-09-29 07:02:47.544) already exists.
2025-09-29 09:02:47.604 CEST [7128] STATEMENT: UPDATE sde.infra_elec_pt_asbt SET gdb_branch_id = 0, gdb_from_date = $1 WHERE gdb_branch_id = $2

This error appears for all tables where posting didn't work. It seems that archived versions of a feature still exist in the branch when the gdb_branch_id is set to 0 and gdb_from_date to the current time, resulting in a violation of the unique uuid index on the table. As far as I can see, only the latest version of a feature is written into the default version, so I assume that archived features inside the branch should be deleted beforehand.

0 Kudos
George_Thompson
Esri Notable Contributor

Can you provide what version of Pro / Enterprise / RDBMS / Enterprise Geodatabase version you are using?

--- George T.
0 Kudos
malte
by
Occasional Contributor

We're currently on Pro 3.6.1, Enterprise 11.4 and Postgresql 14.6.

I just checked the Geodatabase version, most are still on 3.2.1. It might be worth to upgrade and see if it changes something.

0 Kudos
George_Thompson
Esri Notable Contributor

I am assuming you meant Pro 3.5.1 since 3.6.x is not out yet.

I may be a good idea to upgrade your EGDB to match the version of your client. I would do this in a test environment first and retest the workflow (you may need to publish new services from the test environment).

There have been lots of updates since Pro 3.2.x

--- George T.
0 Kudos