arcpy.da.Editor(sde_workspace) yields a Workspace Operation object instead of an Editor

[RogerDunnGIS]

My Pro project contains an sde connection file called Knight.sde.  I am programming in a Notebook.  When I call arcpy.Describe on "Knight.sde" it shows me that it is indeed a Workspace and provides the full path to the file.  However, the following code yields the following error:

with arcpy.da.Editor("Knight.sde") as eddie:
  eddie.startEditing(True, True)
  try:
    eddie.startOperation()
    try:
        with arcpy.da.UpdateCursor("Feature Class") as u_cursor:
          for row in u_cursor:
            # some operation
        eddie.stopOperation()
        eddie.stopEditing(True)
    except:
      eddie.abortOperation()
      if "row" in locals():
        print(row)
      raise
  except:
    eddie.stopEditing(False)
    raise

AttributeError                            Traceback (most recent call last)
In  [65]:
Line 2:     eddie.startEditing(True, True)
AttributeError: 'Workspace Operation object' object has no attribute 'startEditing'

If I print eddie's type in another cell, it shows 'Workspace Operation object' instead of any kind of editor object.  I am totally perplexed, as this pattern of programming has worked in the past.  I have tried a number of different parameters to the arcpy.da.Editor constructor and they all yield 'cannot open workspace' errors so I know that "Knight.sde" is the right thing to pass as an argument.  Why does my Editor constructor give me a weird Workspace Operation object instead?  It's like asking someone for an apple and getting a pinecone instead.

I am using ArcGIS Pro 3.3.1, the latest version available at this time.  I use an enterprise geodatabase on Microsoft SQL Server 2019 that is also the latest version of Esri's geodatabase format at this time, 11.3.0.52636.  I'm using the default Python environment that comes with Pro.

[VinceAngelo]

---

@RogerDunnGIS wrote:

  An exception should be throw in these instances so I know what the issue is and where it is.

---

While that sounds great in theory, it's actually pretty hard to accomplish, at least with enterprise geodatabases.  Data loading, for efficiency, is done as a bulk insert operation. This means that the error isn't encountered until much later, possibly thousands of rows after the data has been staged for array insert.  If you organize your code to COMMIT after each row, then the error can be caught, BUT performance may be degraded by several orders of magnitude (e.g., 5 minutes instead of 300 milliseconds).

If no exception is ever raised, then that is a problem, and a reproducible test case should be submitted through Tech Support.

- V