Select to view content in your preferred language

SDE - 1) Compare child to child before Post, more than 3 at once in Differences 2) archiving children 3) post only certain layers, record or fields

196
1
09-16-2024 07:07 PM
Status: Open
Labels (1)
Kevin_MacLeod
Frequent Contributor

Versioning in SDE does not really provide QA/QC and can lead to unintended data loss if not careful. Documentation does not explain what happens under various orders of operation, particularly with examples, and the system as designed is unforgiving. 

1) 'Undo' for Rec, and for Post.  

2) Add ability to compare child to child BEFORE a Post.  AND to pick Accept/Reject/Modify.  One by one. If desired. Or perhaps modify in some batch manner.  Let's say we have a QA version child to default; and 3 grandchildren. Right now you have to manually copy in values you want from grandchild 1 to grandchild 2, and then both those in to 3, one after another.  If you post up Grandchild 1 to a QA version then Post up 2 with favor editor, you lose any differences that were in Grandchild 1.   But, Post and rec 1 up to a QA version, and you see the Differences in 2, before any rec/post.  So that is helpful.  (usually, not always; too many corner cases to get in to here but they should all be documented, they're not)  You can then manually bring things in from Grandchild 1 as needed. (Oddly it still shows the values as different even if the same; even when using By Attribute conflict, but at least this works in to preserve data from Grandchild 1)    Then, paste both those into 3 in the same manner; and post up again a third time. Then post QA back to Grandchild 1 and 2.  All this to say; versioning is a great way to lose data if you don't get it exactly right.  Right now, it is not the safety net one would think it should be. Almost the contrary.  Conflicts Pane works well but that is a specific edge case. Usually it's a Difference not a Conflict and those will just as soon ovewrite.   And this is why at the very least, if you version you should have an intermediate QA version that then posts to Default. 

3) Archiving for children.  Archiving and Moments are awesome. You rewind back in time. The catch? It's useless for versioning.  Why? Only DEFAULT is archived.  So, that would be a great way to unwind a Post since there's no undo. Unfortunately there is no Archiving for children.  (I think that may be implemented in Branched versioning? Can anyone verify?)

4) Replicas do not appear to copy versions either. Would be nice. Right now, you have to set up a new replica for every single version. Would be great to simply check off which version(s) you want; bop bop bop and create one replica for all versions all in one pass.

5) Show 3 or more differences at once amongst children in a Difference pane. That would be great. In fact it would be great if one could show where something was different between specified versions or where it was different among all versions for one record. 

 

6) only Post certain layers not the whole SDE.  Or, just certain Records; and/or Fields, as based on SQL query. I see a conflict filter GP tool but make this more full-featured.

 

Maybe I'm missing something but I spent a week experimenting. It almost seems more dangerous than just editing Default. Which is also risky to have edited directly.

I was thinking Experience Builder should be #1 for product development but I think making SDE versioning safe to use, might be #1.  Data itself is the most important thing.

1 Comment
Kevin_MacLeod

Having spent more time examing versioning, I also think ability to 'preview' a Post would be great. You know how you get a preview of an 'example' record before and after a Post. One that has a Difference.  Kind of like a def query preview.  Also, I notice even when records differ they are not considered a difference if a reconcile already happened. I suggest this is counterintuitive. If a record's value in a field is different, it should show in Differences.  I suppose there could be an option to toggle whether or not this is only applicable for all differences vs just ones after the last Rec.  Bottom line, the interface is so limited that using more than one version seems prone to error and probably costs more time than it saves unless workers only work in separate layers, or separate geographic areas. (Not always possible)