editor.StartEditing(workspace) crashes ArcMap

[ShawnHolyoak]

I have a desktop addin I've built to copy features from one feature class to another.  I've built other addins before that I get my SDE workspace and start editing it.  I have no problems with those.  For whatever reason, though, this add in crashes arcmap when I call

_editor.StartEditing(_workspace);

The workspace is a valid workspace, the user has edit privileges, and like I said, I'm using the same code in other add ins and it's working.  Is there some setting somewhere that I set wrong that is causing this?  I'm about ready to start over and recreate the add in.  Any help will be appreciated.  Thanks.

[ShawnHolyoak]

I tried a different user, and that didn't work though it did one time.  I stepped through debugging, and it successfully started editing.  I tried a second time and it crashed ArcMap.

[AlexanderGray]

If you put an exception handler do you get any kind of exception or just arcmap crashing?

[ShawnHolyoak]

I thought I had error handling in place, but didn't.  When I added it, I get an insufficient permissions error, which is the problem, of course.  The new problem is, no user, other than SDE, can have edit privileges to all the feature classes in the database, based on our security model.  How do I specify that I want to edit the feature classes in one feature dataset and then start editing just that dataset?  Can that be done?  Do I have to have those feature classes in the map and get the workspace from those feature classes?  Why is this working in my other add ins?

[AlexanderGray]

You don't need permissions on all the featureclasses to start an edit session on the workspace.  You do need permissions on some of them of course.  Can you start the edit through the ArcMap interface?  Do you have versioning on the featureclasses?  Is the editor set to do edit with do/undo?  Do you have some featureclasses loaded in some layers in the map that have edit permissions?  Can you re-run the grant edit on the featureclasses you need to edit?

[ShawnHolyoak]

You don't need permissions on all the featureclasses to start an edit session on the workspace.  You do need permissions on some of them of course.  Can you start the edit through the ArcMap interface?  Do you have versioning on the featureclasses?  Is the editor set to do edit with do/undo?  Do you have some featureclasses loaded in some layers in the map that have edit permissions?  Can you re-run the grant edit on the featureclasses you need to edit?

That's what I thought.  I can start editing within ArcMap itself.  The feature classes are versioned.  I don't believe the editor is using do/undo, though I do use operations when I do the edits (if I could start editing that is).  I don't have any of the feature classes I will actually be editing in the map, as I don't want to depend on them being present if I don't have to (you know how users are).  I'll rerun the grant edit on the feature classes I need to edit, but the error is the same no matter the user.  I get insufficient permissions, with different feature classes throwing up the error, based on the user.  The feature classes listed in the error aren't the ones I want to edit.

I've put all my code for getting the workspace and starting editing below, in case that helps.  This identical code works in another add in.

              private void startEditing() {
   //get the workspace necessary for editing
   _workspace = getWorkspace();

   //get the Editor singleton object and start editing
   getEditor();

   if (_editor.EditState == esriEditState.esriStateNotEditing) {
    try {
     _editor.StartEditing(_workspace);
    } catch (Exception e) {
     MessageBox.Show(e.Message);
    }
   }
  }

  private void getEditor() {
   IUID _ID = new UIDClass();

   _ID.Value = "esriEditor.Editor";
   _editor = ArcMap.Application.FindExtensionByName("ESRI Object Editor") as IEditor2;
  }

  public IWorkspace getWorkspace() {
   IWorkspaceFactory2 _wsf;
   IWorkspace _WS;
   string _server = "";

   try {
    _server = "ServerName";

    _wsf = new SdeWorkspaceFactoryClass();
    IPropertySet _ps = new PropertySetClass();
    _ps.SetProperty("SERVER", _server);
    _ps.SetProperty("INSTANCE", "5151");
    _ps.SetProperty("DATABASE", "");
    _ps.SetProperty("USER", "username");
    _ps.SetProperty("PASSWORD", "password");
    _ps.SetProperty("AUTHENTICATION_MODE", "DBMS");
    _ps.SetProperty("VERSION", "SDE.DEFAULT");
    _WS = _wsf.Open(_ps, 0);

    return _WS;
   } catch (Exception) {
    return null;
   }
  }

[AlexanderGray]

Do/undo is a property of the editor that you set in the mxd.  Basically with do/undo you must have versioning, without you can edit un-versioned data.  This could explain why it works for some add-ins and not others (the mxd being the difference.)  As a test, I wonder what would happen if you loaded an editable feature class as a layer in the map.  Another thing is you check if the editor is in the edit state before starting but there are three states, editing, not editing and editing but unfocused (active map is not the map where the edit session started.)  Your code does not account for the unfocused state, maybe something to look at.  Also it would be interesting to see if you can open a featureclass from the workspace before starting edit to see if it is working correctly.

[NeilClemmons]

I don't work directly with SDE data all that much but if your data is versioned then shouldn't you be specifying the version you want to edit when you open the workspace?  Your code appears to be opening the default version:

_ps.SetProperty("VERSION", "SDE.DEFAULT");

[AlexanderGray]

There is nothing wrong with editing the default version.  It would be ill advised if you have many (>5) users doing it at the same time.  There are many other circumstances where that would not be good, but, in some cases, that is a perfectly legitimate thing to do.

[ShawnHolyoak]

Without changing my code in any way, I returned to this late last week to show a colleague what was happening.  It worked fine, and still does.  I have no idea what could have been going on to prevent the code from working, but it is now working fine. Grrrr.  Thanks all, regardless.