IFeature.Store seems to bypass edit sessions and cannot be rolled back. Why?

Question

I'm working with ArcObjects edit sessions for the first time and am having some trouble with it. The C# code I am about to discuss is part of an ArcMap 9.3 extension DLL.

My problem is that calls to IFeature.Store inside edit operations seem to simply bypass the edit operation (and edit session) in which they execute.

This is my code:

IFeatureWorkspace workspace = …;
IWorkspaceEdit workspaceEdit = (IWorkspaceEdit)workspace;
if (!workspaceEdit.IsBeingEdited()) return;

// at this point we know that we are inside an edit session.

IFeatureClass featureClass = workspace.OpenFeatureClass(…);

workspaceEdit.StartEditOperation();
try
{
    IFeature feature;
    IFeatureCursor features = featureClass.Search(null, false);
    // (ESRI recommends search cursors inside ArcMap, even when updating inside edit sessions.)
    while ((feature = features.NextFeature()) != null)
    {
        feature.set_Value(…); // only as an example; assume that the feature is modified somehow.
        feature.Store();
    }
    workspaceEdit.StopEditOperation();
}
catch
{
    workspaceEdit.AbortEditOperation();
    throw;
}

As you can see, the edit operation in this code modifies all features in some feature class.

Let's say that after a few successful feature updates, one update throws an exception. The exception handler in the above code would then call workspaceEdit.AbordEditOperation();. As I understand it, this should rollback all modifications done inside the edit operation (including the previous, successful feature updates). I am however observing that the effects of feature.Store(); never get rolled back.

I have also tried this with IEditor.StartOperation/.StopOperation/.AbortOperation instead of the IWorkspaceEdit methods, but that doesn't change the observed behaviour.

Can anyone explain to me what I am doing wrong? How can I rollback the effects of IFeature.Store in an edit session?

Answer 1

I found the cause of this problem. The problem is not with the code, but with ArcGIS licensing and the specific set-up of the feature class I was editing.

• The feature class referenced by featureClass participated in a relationship class.
• I was executing the above code under a ArcView license.

(Why would I do that, you ask? As you may know, editing (in ArcMap) feature classes that participate in relationship classes requires an ArcEditor or ArcInfo license. I found out, through experimenting, that one can update (via ArcObjects) such feature classes with only an ArcView license!)

Incorrect behaviour of edit operations and sessions seems to be a side effect of working under an ArcView license. When I switch back using Desktop Administrator to an ArcInfo license, my code above works just fine, including undo/redo.

Answer 2

Personally, I only use iEditor/iEditor2 interfaces for edit sessions and edit operations. You say you are working on an ArcMap extension so you should use iEditor sessions/operations since it is available. (IWorkspaceEdit is a lower level interface for use when the Editor is not available - in engine environment see page 40 of presentation) I think you still can use iWorkspaceEdit even when iEditor is available but you must also follow rules for correct object editing on a geodatabase. (see remarks)

I am not sure why you are having issues with the IEditor.AbortOperation method not undoing changes after calling iFeature::Store. Upon calling this method "all the changes made after StartOperation was called are undone, and nothing is added to the operation stack." Difficult to say what's going on without seeing all of your actual code. As for handling errors there are also recommended best practices; "if an error during an operation should cancel the entire session, the session should be placed within the block, whereas if only the operation should be aborted, just the operation should be wrapped within the block (possibly re-throwing the exception if it is an unrecoverable error)" (article found here)

With respect to calling the IFeature::Store method on the object; Store should not be used for batch operations, such as updates or inserts. "Stored and deleted objects within an edit operation are automatically and periodically flushed to the underlying database as needed to ensure read/query consistency and update efficiency."