nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Discard all changes in a version

Anonymous User

Dear all

I would like to know if it is possible to discard all changes in a version, this is, "move" the version to the same state of the parent version, without delete the version.

We would like to "approve" or discard bulk changes made in a version.

Best regards

Jesús de Diego

Vind meer berichten getagd met

Accepted answers

All comments

Anonymous User

mm... this is not the "direct" or automatic way we were expecting...

Any other alternative?

Regards

Jesús de Diego

Anonymous User

Thank you Pieter

We would like to avoid direct editions on A/D tables....

Regards

Jesus de Diego

MartinAmeskamp

OK, I can see what you're trying to do. In interactive editing, you'd open a version for your edits, pass that version on to some QA step, and then either post or discard the changes. When using a feature service and having the client doing the sync directly through the feature service, I don't see how you can identify the changes made in one particular sync in order to undo them. Generally, you may have more than one server process for the feature service (be aware that synchronizing the reconciles of these processes may become painful), and maybe someone's doing a compress in the background, changing all your state IDs anyway...

Depending on the importance of this feature, you might want to have a look at the basic structure of your service: Maybe you want to set up some custom service on top of the feature service that allows you to do some QA on your user's results before actually syncing back to the feature service's version?

Martin

MartinAmeskamp

Well, I agree that this is dangerous: For one thing, the edits made in a version will not generally all share the same state ID (that's where state lineages come in).

If you really want to fiddle around with these internal details, at least make some experiments and use GDBT to see what the version/state tree looks like at each state and what effects your actions have. Also, have a look at the versioning ebook published by ssp innovations: http://sspinnovations.com/everything-you-need-know-about-versioning-arcgis%E2%84%A2#.VrNCTVKu9oc

Martin

Pieter_Geertvan_den_Beukel

not tested, supported and dangerous: in the sde.VERSIONS table you can find the state_id of your version. Use this state_id to delete records from the A* and D* tables where sde_state_id = <state_id>

Anonymous User

Hi Martin

First of all, thanks for your answer. The workflow you mention is not possible. We are thinking in this scenario:

- We have published some feature classes as feature services in AGS. The feature services points to one specific version, let's call "Version A"

- CAD templates have been created using ArcGIS for AutoCAD against these services.

- External users can edit these templates incorporating new elements, but also editing existing ones.

- The resultant CAD files can be synchronized through the services and changes will move to the version.

If , e.g., the whole data in one CAD file is not correct, we would like to "reject" or "discard" all these changes.

But:

- We can create new "subversions", but synchronization will produce anyway against the version "Version A"

- We would like to avoid deleting the original version "Version A".

Minor editions can be performed during the revision phase in "Version A", once the CAD data have been incorporated to the version, but we would like also to have the opportunity of revoking all changes.

Regards

Jesús

MartinAmeskamp

Hi Jesús,

why would you want to do that? Anyway, without knowing the constraints of your environment, using a second version inside the first might be the way to go: Discarding all changes means rolling back a long transactions, and long transaction are implemented by versions in ArcGIS. So if you want to roll back your changes while keeping your transaction alive, use a second layer of transactions: Create verison V1 off DEFAULT, and then create V2 off V1 before you start editing (in V2, of course). Then you caeither post your changes to V1, or delete V2 to return V1 to its original state. As long as V1 has only one subversion, there shouldn't be any noticeable performance overhead.

Martin

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.