AnsweredAssumed Answered

Is this correct? Pro-editing versioned feature classes published to a federated server result in extra child versions that revert edits and do not unregister.

Question asked by tpcolson Champion on May 18, 2018
Latest reply on Jul 6, 2018 by tpcolson

In SDE 10.6.1 GDB (SQL 2014 CU11 ENT), create a database. Provision with a point, line, and poly FC using Geography storage type, and add a photo attachment able to the point FC. Enable editor tracking on all, register as versioned but do not check the “Move edits to base” thingy. Then enable archiving on all. Create a child version.

In Pro, add the 3 FC’s to a map using the child version connection string, share as web layer, share to PTL 10.5.1, and pick a federated (not hosted) 10.5.1 server, where the SQL GDB is a registered data store using the default version, and where there is also a registered data store using the child version in the connection string. Enable the time zone do hicky, and check export data and sync and feature service. Validate reports no errors, and yes, you are using the child version, and the child version data store. Publish to the root of the server (no folder stuff).

 

In Arc Map 10.5.1, add data from PTL, create local copy for editing. In Pro, GDB Connection properties, note that no versions have been created. In Arc, drop a few points, delete some, etc…sync back to server. Note how the data synced in the map view in Arc, and in a Portal map, and looking at the map service on another Arc Map different computer. All are pointing to the same child version that is driving the service.

 

In Pro, add the same service to a map (from Ptl), download the map. Note that a new child version [username_unixtimestamp] is under the original child version in GDB connection properties. Add some new points, delete some. Hit sync. Happens…really fast. Go to PTL, none of your edits are shown in the service, which is driven by the first child under default. Make more edits. Sync. More edits. Hit remove. Wait for it…….all your edits are now gone! Note that child version [username_unixtimestamp] still exists.

 

I’ve figure this much out: your edits are syncing to the “child of the child” that was created when you hit download map. However, when you remove the offline map, guess what? Your edits are reverted in the child-of-child version! They’re gone, as is the SQLite GDB that gets created when you download the map.

 

I can’t imagine how this would be the expected behavior. Imagine a database with 6 child versions under default (for regions of the country). Each child is pushing its own feature service. 100 users hit each child in Pro, and “Download Map”. There’s now 100 children that now need to be rec’ed and posted to each child.....and why are the edits removed when I remove the offline map?

 

I haven’t tried this with “Moving edits to base”, but that’s a versioning workflow I don’t support, and I can’t find in the documentation where not checking move edits to base results in this behavior. It’s entirely possible I’ve missed a checkbox somewhere, but I’ve checked them all on and off and get the same behavior.

 

Confident this is an operator headspace error and one of you know the correct box to check....

Outcomes