IEditor vs IWorkspaceEdit2 Question

[GregRieck]

Hello All,

The database is an SQL Express 2012 versioned database. ArcGIS 10.2.2 Standard. W7 x64 SP1

Why would   IEditor3.EditState == esriEditState.esriStateNotEditing  be true when if(!IWorkspaceEdit2.IsBeingEdited())  be false on the same IWorkspace? And when should you use IMultiuserWorkspaceEdit?

Thank You.

[Anonymous User]

Good questions.

IEditor.EditState reflects the state of the editor object. It will only show esriStateEditing when you have successfully started editing in ArcMap from the UI or programmatically started editing a workspace through IEditor.

If you programmatically start editing a workspace through the geodatabase interfaces, the editor wont reflect this.

When programmatically editing objects in enterprise geodatabases (sde), you should use IMultiuserWorkspaceEdit.

[GregRieck]

Hi Sean, thank you for responding to this question.

I figured out part of the problem. The table that I thought was registered as version wasn't.

So, I'm a bit confused on the IMultiuserWorkspaceEdit interface. It uses IWorkspaceEdit to start and stop operations as well as stopediting. But elsewhere in the Editing documentation  I find the following:

ArcObjects 10 .NET SDK Help

• Developers of custom ArcMap components (that is, commands and extensions) should use the editing interfaces in the ESRI.ArcGIS.Editor assembly rather than those from the ESRI.ArcGIS.Geodatabase assembly; in particular, the IEditor and IEditor2 interfaces. For more information about editing with the Editor, see Managing edit sessions and edit operations.

So this isn't the case with IMutiuserWorkspaceEdit? In that case I should use IWorkspaceEdit instead of IEditor to start / stop operations and stop editing? Is it just me or does the entire Editing documentation need a complete overhaul?

The only reason I would even think or know to use IWorkspaceEdit instead of IEditor is because the table under Versioned editing in ArcSDE geodatabases uses methods from IWorkspaceEdit, see the same link above. Yep, right there on the same page. Near the top Developers are urged to use IEditor and then a little farther down under versioning the methods being used are from IWorkspaceEdit.

So now you come along and tell me again use IEditor? Sean, I'm so confused! Please clear this Editing mess up for me in a way that is clear when I should use which interface and methods. I need to understand when I should use EditState vs IsBeingEdited() and IsInEditOperation.

Greg

[Anonymous User · Accepted solution]

Hey Greg,

I'll try to clear up the confusion. As a developer you're in control of your own destiny and you can certainly do things you wouldn't normally be able to do through the UI which sometimes works or can lead to bad application states.

If your developing components or extensions for ArcMap, particularly those that interact with the display, you should manage edit sessions through the Editor Object. For other applications, or if you know what your doing, you can go straight to the geodatabase interfaces. Architecturally the Editor assembly sits on top of the Geodatabase assembly so when you make those edit session management calls with the editor object, behind the scenes it forwards them to the geodatabase assembly (e.g IEditor.StartEditing calls IWorkspaceEdit.StartEditing with some extra stuff specific to the map).

If you decided to use the geodatabase interfaces and are editing an sde geodatabase, you should use IMultiuserWorkspaceEdit to start the edit session. You would then use IWorkSpaceEdit to manage everything else (stopediting, the edit operations etc).

To determine if a workspace is in an edit operation you can call IWorkspaceEdit2.IsInEditOperation regardless of how you started the edit session  Its highly unusual that a workspace would be in an operation that you don't know about, so that's one concern. If you try to start an operation when one exists, you'll get an exception.

For further reading you can look up:

Managing edit sessions and edit operations (editor)

Editing with the geodatabase API (geodatabase)

IMultiuserWorkspaceEdit Interface

For your case of updating the table (geodatabase table?) it should be fairly straightforward. The geodatabase topic Updating features shows an example (but without the start editing part). You mentioned you tried all the start edit methods but what was the error message returned from those?

Sean

(might be a slight post overlap here I posted this without seeing your previous post. Glad you got it working and let me know if you have any other problems)

[GregRieck]

Sean,

The error I received was something along the lines of must be contained in

an edit session. But I think the problem was that the table wasn't

versioned.

Everything you've stated was the expected response, so that's good. The

only thing not mentioned is EditState vs IsBeingEdited. Should I always use

EditState since it's on the Editor?

Greg

[Anonymous User]

Greg,

The non-versioned data always trips people up.

One thing I should have mentioned is that IEditProperties3.MultiuserEditSessionMode determines how the Editor object behaves with versioned editing. On the UI this is set through versioning tab under editor options. The default is to edit versioned data.

EditState vs IsBeingEdited.

If you've decided to use the Editor to manage the edit session then use you would use EditState to determine if you need to programatically start an edit session (the user may have manually started one already). Alternatively you can tie your command (button or tool) into the EditState such that its only enabled when the user has started editing.

e.g.

    protected override void OnUpdate()
    {
      Enabled = (m_editor.EditState == esriEditState.esriStateEditing);
    }

IsBeingEdited only determines if the current application has started an edit session on a workspace, so if you go down the geodatabase interface route you would use this method.

If all your doing is quickly going out to the geodatabase to update a standalone table then you can probably get away the geodatabase interfaces (IWorkSpacedEdit/IMulti). It all depends on the scope and complexity of your customization. Going through the Editor object is safer and recommended if your doing anything that would affect the display (the renderer, selection sets etc) or you want the Editor UI to light up in the context of further operations.

[GregRieck]

Sean,

Thank you for the details, it has helped me better understand what I need to do.

Greg