Is there a way to compare between multiple child versions of Default? To review Conflicts BEFORE posting? (same field of same feature)

Question

Is there a way to compare between multiple child versions of Default? To review Conflicts BEFORE posting?

The 'Differences' pane to review differences between a child and parent works as expected. Same for Conflicts.

Ideally, I want to see between two or more children, if the same field in the same record (feature) is edited and differs.  Or if geometry differs on the same feature between two versions.  It would be great to see this before posting to Default.

I fear this is not possible. Doesn't seem like it based on experimentation. Which is rather surprising. I have nearly ten child versions fed by various REST services as well as from full analysts from editing in Pro. I am wondering how to QA/QC.

I also have been reading and it seems that when there is a difference between two Child versions when posting both to the parent Default, the more recent edit will be taken.  Many times that is great. But what if the more recent edit, was a mistake?   I am just beginning to deploy versioning to my agency.  At least at first, I want to QA/QC stuff coming in, until I feel confident we are receiving good data from the field operators. And I will perpetually want to spot check. Of course, I mainly want to check when there are conflicting edits. between children. (same field/same feature; or geometry of same feature).   How can this be done?

For now, seems like the only way is to have an intermediate 'QA' database version the children point to, and then one by one, post edits to that and look at conflicts between the two; and after posting and reviewing all children; post this intermediate QA version to the master Default grandparent.  Still wondering though, how to see all at once; the difference on a particular feature between multiple versions. This approach I just thought of with a 'QA' database, would work fine for two children. But what if I have 7 or 8?  Seems like this would be rather tedious to review one to one to one to one. I wish the Differences Pane would show all versions not just one child at a time compared to the parent. I noticed it only shows whatever happens to be highlighted in the Table of Contents in Pro.  Thoughts?

Kevin_MacLeod · Answer

After experimentation I found that the Esri tools for versioning lack a way to compare differences among editing versions. Basically, no way to QA.  Documentation is minimal, and so I experimented. I am at 10.91.  Bottom line: there is no way to compare child to child, before Posting.  If you have only two children, no problem as I outline below. You can post one, and then look at Differences.  But when you have 3 or more.... there's nothing to help you.  It's full manual copy and paste.  I can't see how this scales. There is no Differences pane for comparing Child to Child, especially multiple Children. (Would be great to see Diffs between 3 or more. And a Venn diagram of records differing in all or in perhaps selected key versions where you want to know what is unique)

So It's possible to keep edits from one child to another while going through each child and Posting.  It is time-consuming and manually done.    Here's the deal. You'll need an intermediate QA version as a child of Default. Then let's say we have 3 full analysts each with a grandchild.  If some edits are in Gran1, Gran2 edits some of the same records and a few new ones, and then Gran3 also has some overlaps and some unique edits.  Well if we post and rec Gran1 it goes up to the parent, let's call it QAVersion.     If we move to Grandchild 2, we will need to manually copy in any conflicting edits from Grandchild1 that we don't want overwritten.  Otherwise, they got overwritten in by Gran2.  I tested.  And when I say conflicting I mean those that show in Differences, not "conflicts".   Then, same for Grandchild 3. What that means is it's manual decisions for each difference, if we want to retain those from Grandchild 1 or 2 when Posting from 3.  Then after doing those posts; we must then Rec back down to 1 and 2 each Grandchild has all changes from each other.   This is not a reliable and scalable way to QC.

Also, it's disappointing in the Post / Rec user interface there is no way to only post certain layers and/or Post/Rec only for a certain number of records based on SQL def query.

It makes me wonder how large organizations with many editors manage data or what software they use. I hope Esri can implement SDE Child to Child QA comparison tools soon.

I tested all this with traditional versioning.  Does Branched also lack comparing children?

Also, Archiving only archives the DEFAULT and does not archive child versions. I really wish it did.  I think Replication can be set up to copy each child to its own GDB ("Geodatabase Connection Properties" set to each version as its own Connection file and replication created)  I am testing.

It seems the only good way to back up an entire SDE in one shot simply is a SQL Server backup file but unfortunately I don't have access to SQL Server or the Server. The only thing I'm admin of is SDE from Catalog, not even my own laptop.

If Replication doesn't work for each version I will try using python to back up each version of each layer in SDE daily, before Posting, as a safety net.    Since...I have seen for example through testing, sometimes a difference won't be flagged as a 'difference' in the Differences panel. There are so many permutations of the order of operations; and most of it is not documented. They should definitely document variations in behavior using at least a child and three grandchildren, to demonstrate when and if data will post over other data from another child at the same level.

Now that I've delved into it, there should be a way to Select different records in the attribute table, so as to visually visualize them. The lack of QA/QC for Versioning is the most critical platform issue I have seen in 20 years in GIS, because of the risk of inadvertent data loss. I can deal with minor issues with Pro UX or Exp Builder needing a while to catch up to WAB but potential data loss, is altogether different.  I can't think of anything more critical or pressing for the backend. A Version QA/QC interface needs attention before almost anything else, from the Data Management team.

Also what is disconcerting in all this, is I noticed Arc Pro is even more unreliable at refreshing data than ArcMap was.  Frankly I've always been frustrated stuff doesn't refresh automatically every few seconds.  But with Pro, even clicking refresh when dealing with Versioned data sometimes doesn't work. I've also seen this after editing data through an app via REST.  Only closing and re-opening Pro refreshes it. (Pro 3.3)  Also the Total number of features sometimes is just ... wrong. (clicking Load All to compare the number before and after a Post for example)  Just a sidenote but it all ties in to being able to trust the software. Also, I haven't seen this much crashing since older ArcMap versions. Several day. Windows 10 latest version, SQL 2017, 10.91 SDE database version, Pro 3.3 so a very common or probably the most common denominator of Arc.

Lastly if number of features differs after post and rec it is not reported as a Difference.

And really lastly, why isn't there an Undo for Rec and for Post?  Ugh. Would be great to have that and to have Archiving for children.

Kevin_MacLeod · Answer

I am also wondering, how to protect overwriting data from one child to another child.  If Child 1 has hydrants has updated attributes in A and B.  Child 2 has updated attributes in two other Hydrants, C and D.  So, two completely different features.  If I post child 1 and then child 2; won't the A and B data from child 1 get overwritten with the old data from the last time the parent was posted back down to the child 2; and then posted back up from child 2?  How can updates from child 1 be protected or marked as 'approved'?  I was thinking, if there was a field you could set to 'approved' or something; you could filter the Posting to only post to rows where the field was null.  But apparently.. no?   https://community.esri.com/t5/arcgis-enterprise-ideas/using-reconcile-post-with-subset-data/idc-p/1537104    It seems like the answers here are separate people work on separate layers or geographic areas of a layer. I do see a Conflict Filter tool in the Version toolbox I will experiment with; hopefully it can also completely stop certain Children from Posting to some featureclasses altogether.

Kevin_MacLeod · Answer

I meant to post the Question above from my own handle. Hoping to get notifications on this now. (It appears one can't Subscribe to someone else's thread?)