When Versioning with ArcSDE can posted edits be cancelled or rejected? [closed]

Question

I am using ArcMap 9.3.1 and attempting to work with an ArcSDE geodatabase (with one polygon feature class) that has already been registered as versioned. I'm new to versioning and am still trying to figure out some of its basic functions. So far, I haven't been able to discover if it is possible to "cancel" or "reject" certain edits once they've been posted to a parent version.

For example, let's say we have three versions: the original SDE.DEFAULT that was created when it was registered as versioned, a child version of the default called SDE.QA (for Quality Assurance), and a child version of the QA called SDE.Edit1 (where the edits first take place).

If certain features of SDE.Edit1 were edited (e.g., to keep it simple, let's say one polygon was added and one was removed) and then SDE.Edit1 was reconciled with the SDE.QA and subsequently posted to SDE.QA, would there be any way to later undo this change?

Following up on this question, would it possible to reject only some changes?

For example, accepting adding the first poly, but rejecting removing the second poly.

As far as I can tell, once edits have been posted to the parent version, all these changes are now a "permanent" (for lack of a better word) part of the parent version. I am aware of the fact that these changes are all recorded within two tables, the "ADD" and "DELETE" tables (often referred to as the "delta" tables), and don't actually change the original FC itself. I considered looking into manually altering these delta tables, but I found enough people warning against that to know that it's likely not the right solution.

Perhaps it is my understanding of versioning that needs some work, but I couldn't seem to find a way to reject a change or undo a change once it's been posted. This seems strange to me, as this would mean that there is no way to undo a post which contained an error. I also can't seem to find a way to trace the lineage of these versions (i.e., which version is the child of which parent).

While I'm on the topic, do you know of any particularly useful ArcSDE references (links, articles, books, etc) that might help with my understanding of ArcSDE (and perhaps answer some of these questions)?

---

Although answers so far have been helpful, I still cannot find an answer to the core of my question. Again, perhaps it is my own misunderstanding of the situation. Here is what I want to know:

**Can you reverse (by reverse, I mean undo) a post once it has been made from a child version to a parent version?

In this scenario, the parent can be, but doesn't have to be, the SDE.DEFAULT version.

Even better, I would like to know if you can reverse a part of a post (say, a single edit to a polygon), after it has been posted?

I would also like to know if this can be done without the need to have had any conflicts detected.**

The fact that I can't find a clear answer to this question (i.e., "yes" or "no") documented anywhere makes me think I am missing something important about versioning in the ArcSDE. I would also prefer to avoid manipulating the A and D tables manually.

Answer 1

Ugh. The answer is really a complicated one that requires a lot of ArcSDE background, so I will try to be as brief as possible.

Note I am going to refer to some diagrams from the super awesome versioning white paper that you can find in the ESRI site. If you are dealing with versioning, I extremely encourage you to read it throughly.

Then, you need to understand what is the relationship between a state (i.e a node from the state tree) and a named version (i.e a label pointing to a state).

A typical database may look like the state-diagram below:

Here, you have four versions in the database (Version A, Version B, Version C and DEFAULT). But perhaps, I am getting a little ahead of myself. Let's start with what a state is.

You can think of a state as a "transaction" - a logical unit that contains several edits to one - or many - tables. It may include two inserts to "FeatureClass A", a delete from "Feature Class B" and a modify (effectively a delete + an insert) to "Feature Class X". All grouped into one.

Let's look at a small, simple, ArcSDE state diagram that starts at state id 0:

If you start at state 0 and you do edits to one or many tables in an edit operation, you will create a child state 1 and make that one the current active state id. Another subsequent group of edits will create child state 2. If you want to undo, you don't need to modify the state id in any way - all you need to do is change the current active state id to 1, or 0 (depending how far back you want to go). A redo is the opposite - just move the current active state id forward - as far forward as you want to go.

That is how undo/redo works in ArcSDE versioning.

OK, moving on. Say, that you want to make an edit permanent (i.e, you want to save). What do you have to do? Well, saving is just grabbing a version label and moving it forward to a particular state. Kind of like stamping it and saying "this is what Version A must look like". So if you look back at the first diagram, you will see that it has four named versions.

• Version B points to state id 1

• Version A points to state id 3

• Version C points to state id 5

• Version "SDE.DEFAULT" points to state id 4

  Please note that this diagram, despite popular belief, does not tell you anything about the logical parent-child relationship that they have. The logical parent-child relationship for the first diagram could effective look like this:

This is the parent-child relationship that you see in ArcMap/ArcCatalog. It's purpose, is to restrict which versions you can reconcile against. At this point, you could (rightfully) be asking yourself, why the hell do I need this? The answer, lies in versioning workflows. Turns out, people have been using versioning for quite some times and there are some preferred ways of how to structure these, but that is a topic for another day since I want to answer your question today :)

Moving on...

OK, so what else do this named versions do? Well, they affect how this process called compress behaves.

Compress is all about grabbing intermediate states that may not be necessary, and removing unnecessary ones as well as combining them. You can trigger the ArcSDE compress operation through ArcCatalog, setup a service that does it every one in awhile, and some ArcMap edit operations will trigger mini-compress operations (i.e just for small branches that are being used).

The diagram on the left shows a state tree before it gets compressed, and the one on the right shows it right after it gets compressed:

An important concept to understand (which I will refer to you once I finally get to answer your question) is that every single state is a potential candidate to be compressed - except states that have labels (i.e named versions) pointed at them.

You can see that before the compress there are some extra - unnecessary states. In fact, the entire [3,4,5] branch got removed. Had there been a named version at 5, the end result would have been very different.

Compress operations are there to save space on your database by removing records you do not need anymore.

OK, moving on.

The last concept that you need to understand, is reconciling - which is effectively merging two branches into one.

So let's go back to our very first diagram. Say that you want to reconcile Version A against SDE.DEFAULT.

Let's recap: four named versions pointing to various state ids. So the first thing that we have to do, is create a child state under the target version, so we create a child state under state id 4, in our example, I call that state id 20.

The next step is to calculate the differences between both versions (the details are too long for this post, but I can tell you that they are done with difference cursors) and then applying those differences to that new state id 20 (blue line).

Say that you decide to do more edits or that you found conflicts and are choosing rows from one version, or the other. It doesn't matter. Those are just new edits, and are done inside an edit operation, as child states underneath the branch that you merged. In this example, I have done two more consecutive group of edits after the reconcile.

Lovely.

So now say that you are ready "post" the version. What does that mean? That is just grabbing the labels and pointing them to the same state id. Here, I am going to post Version A to SDE.DEFAULT. This is what it looks like:

TADAAA! So now Version A and SDE.DEFAULT are pointing to the same state id, and thus they look the same.

OK, so now I can finally answer your question.

Can you undo a post? The ArcGIS documentation will tell you no - don't mess with it. Don't do it, because you will be messing with this logic, and if you don't know what you are doing, you can corrupt your data.

But in truth, all it takes is to do one update of one of the ArcSDE Versioning tables - the VERSIONS table, and modify the entry of the label (aka named version). In our example, point to state id 21, and you have just undone that entire edit operation. Set it to 3, and you just undid the entire reconcile. Set it to 5, and now you are in a completely different place. Whether there are or there are not conflicts is irrelevant.

Of course, this assumes that a compress has not happened. Let's consider the case where the compress is happening right at the exact same time you are updating the SDE table. Remember, if you - or somebody else - executes a compress after you posted this is what the tree looks like:

Can you undo the reconcile after the compress? Well, in this case, no. The compress has blown away that entire branch, so you cannot undo - that data has been removed. Had there been another named version on that branch, then the compress would not have destroyed that branch. I hope that by now this makes sense.

So should you do this? Up to you, if you don't know what you are doing, you can easily loose data after a compress.

Answer 2

Short of knowing the version and db. here is some initial information that will help you.
Basic admin
Here is some info on rec and post
So if you apply these concepts and use the version changes command you still have the opportunity to reject those changes when you rec and post to default.

You don't have three copies of the same database.
You have one copy with versions.
If you are administering this db you really shoud spend the time (maybe even money) and become familiar with all of this.
The esri class Versioned Editing Workflows for the Multiuser Geodatabase is free and will help some.
But the full monte would be what I recommend for a person administering any kind of versioned sde editing workflow.
That class is Great! for understanding Versioned Editing Workflows for the Multiuser Geodatabase.

Answer 3

I have a "quick and dirty" way. Switch ove to the default version and edit something about the polygon that was deleted. Then when you reconcile to default you'll get a conflict. Right click the conflict and tell it to use the pre-reconcile state. It works for me.

Answer 4

Yes, you could do this, but you will have to do it using SQL.

I DO NOT CONDONE THIS, DO THIS AT YOUR OWN RISK. ALWAYS BACK UP YOUR DATA BEFORE EDITING SDE MANUALLY.

You can query the sde.versions table to get the state_id from the version that you posted with the changes you want to undo. Then you can go to the A and D tables and delete the entries that match the state_id.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Now you have the state_id of interest. Now you need to find the A and D tables for the feature class. You do this by querying the table_registry. The value will be the registration_id. So to get the A and D tables, just add the registration_id to the A and D.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

Then just query both A and D table and delete the entries that have the state_id from the above query.

To find out more about the parent and child relations, just query from the following sde tables.

    state_lineages
    versions
    states

These all have relationships and should help you follow the bouncing ball.

Answer 5

It is not possible to undo edits once they have been posted from a child version to the parent version. See: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

The post operation cannot be undone, since you are applying changes to a version you are not currently editing.

You can review edits made in each version during the reconciliation process--this would be your chance to reject certain edits. The reconciliation process is explained here.

Answer 6

Yes, as others have said the short answer is no.

SDE versioning is so promising but it is unfortunate that its workflow assumes only forward change in features.

Fully-featured versioning in SDE would offer tools that-

• Allows (feature-level) rollback and accept/reject
• Would allow undos
• And would allow undos of previous states (ie starting from stat 3, undo the changes from state 1 but keep the changes from state 2).

This would them be like a SVN source code control versioning system but for spatial features.

Answer 7

The simple answer is NO.

The intention of posting a version is to commit those edits to the target version.

Rollback is accomplished by not posting the version (and it is good practice to delete any such abandoned versions).

While editing the version, the editing application (for example ArcMap) may provide various levels of 'undo' and the user can choose to save / not save such edits to the version being edited.

But after posting to a target (e.g sde.default) the only way to undo is via hacks to the sde system tables.