Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
Did it not raise an error when while using ArcView license? What type of relationship did you have defined on this particular feature class? –  Jakub Sep 28 '12 at 15:47
    
@Jakub: Warnings: ArcMap under ArcView license doesn't allow editing the feature classes involved in a relationship class. ArcObjects does allow it, and won't give any warning! Type of relationship class: There are two feature classes: Routes (the "origin") and RouteSegments (the "destination"). I've set up 1:N relationship between these via a primary key / foreign key field pair; I've also enabled notifications from origin to destination (such that when a route is deleted, all associated route segments are deleted, too). –  stakx Sep 28 '12 at 16:47

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."

share|improve this answer
    
+1 for the nudge to use the IEditor2 interface. I've arrived at the same conclusion, since it integrates much better with the ArcMap UI (Undo*/*Redo in the Edit menu, Editor toolbar, etc.). Edit sessions and operations controlled via IWorkspaceEdit seem to remain invisible to the ArcMap UI. –  stakx Sep 28 '12 at 16:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.