I have a really basic geoprocessing script that's published to ArcGIS Server 10.2.2.

It basically just reads in a json object that's passed in as a parameter. The json just has attribute names and values, as well as a geometry in wkid 4326.

All it does is open an InsertCursor to create features in one specific feature class.

Nevermind asking me "All you want to do is create a bunch of features, why don't you do this in the rest endpoint?" Long story short, I tried several times using the jsapi, and even building my own geometries. In both cases, I got "d is not applied."

Anyway. This Geoprocessing script does work. But sometimes I check the logs and see "SEVERE: 'Cannot open SCHEMA.FEATURECLASS'. Failed to execute (Name of GP service). Failed to execute (name of GP Service).

What would cause this?? I noticed that on times where it works, it was very early in the day (5 AM). And then someone tried to use it around 10 AM and the script fails. From my DBMS knowledge, the only reasons I can think of why someone can't open a feature class for inserting:

  • Someone has a schema lock (I find this less likely since you usually can't get a schema lock on anything if the ArcGIS Server is running)
  • A database transaction is in progress (I don't see any evidence of this since the only other system that loads data into this database shows no records of any loading happening around the time of the error log
  • does arcpy.da.insertcursor fail to open if there's another insertcursor open simultaneously? (I hope not...)

Other info:

  • This is not a versioned feature class
  • The arcpy.env.workspace is set to an sde file that connects as the geodatabase admin. This connection is set to use the default version
  • Here are the properties on the service enter image description here

    #CODE SNIPPET - This is 90% of the business logic here
    loadCursor = arcpy.da.InsertCursor(Feature_Name, fields)
    oids = []
    for feature in FeaturesToAdd:
        geom = feature["geometry"]
        point = (geom["x"], geom["y"])
        attributes = feature["attributes"].values()
        row = tuple(attributes)
        print len(row)
        oid = loadCursor.insertRow(row)
    del loadCursor
    print oids

What else would cause arcpy not to be able to open a feature class for inserting?

Here's the basic code snippet for doing that:

loadCursor = arcpy.da.InsertCursor('SCHEMA.FEATURECLASS', ['field1','field2', 'field3', 'shape@XY']

there's nothing else that opens up any cursors, lists fields, queries the db. etc. This is the only line (not including loadCursor.insertRow())

  • Are you closing the Cursor after you're done with it?
    – Mintx
    Feb 19, 2016 at 20:22
  • Yep. Now that I think of it... the Oracle database underneath might have a timeout of less than 1800 seconds (30 minutes). But the failure case shows that the gp service was idle for several hours which should have made the process shutdown. Then the new request would have created a fresh database connection. Still I should probably knock down the idle time.
    – C. Tewalt
    Feb 19, 2016 at 20:32

1 Answer 1


does arcpy.da.insertcursor fail to open if there's another insertcursor open simultaneously? (I hope not...)

Yes it will fail, as this guarantees database integrity. From the ESRI guide on Cursors and Locking:

Insert and update cursors honor table locks set by ArcGIS applications. Locks prevent multiple processes from changing the same table at the same time.

Update and insert cursors cannot be created for a table or feature class if an exclusive lock exists for that dataset. The UpdateCursor or InsertCursor functions fail because of an exclusive lock on the dataset. If these functions successfully create a cursor, they apply an exclusive lock on the dataset so that two scripts cannot create an update or insert cursor on the same dataset.

A cursor can released by one of the following:

  • Including the cursor inside a with statement, which will guarantee the release of locks regardless of whether or not the cursor is successfully completed

  • Calling reset() on the cursor

  • The completion of the cursor
  • Explicitly deleting the cursor using Python's del statement
  • I wonder if I can make my script check/wait for an existing lock to be released. If I knock down the max instances to 1, that will help, but there's another system that loads data into the sde database using COM arcobjects in a .NET application. I'm guessing the cursors in those also acquire exclusive locks...
    – C. Tewalt
    Feb 19, 2016 at 20:43
  • You can certainly wrap parts of this in try/except though you should probably make sure the other system that loads data won't fail catastrophically when you have the lock. ;-)
    – Mintx
    Feb 19, 2016 at 20:51
  • Exactly... I think the other system starts an edit session, and then saves edits. Based on that link you sent, I think I could probably convert my python code to use an edit session as well. That should make it so it only gets the exclusive lock when the edits are saved, and not during the lifetime of the cursor object.
    – C. Tewalt
    Feb 20, 2016 at 2:03
  • By the way, never said thank you! I'll try reproducing the issue in the customer's dev environment, and then try to fix with this in mind. I've +1'd, but if I fix the issue by fixing the locking, I'll happily mark this accepted! :)
    – C. Tewalt
    Feb 20, 2016 at 2:09
  • Looking at the editor class in arcpy. I want to convert my code above to use an edit session. desktop.arcgis.com/en/arcmap/10.3/analyze/arcpy-data-access/… It almost seems like "multi_user_mode" should be "false" when doing an edit session on a non-versioned dataset, but it doesn't really explain "why". (Perhaps I should ask this in a separate question. I'll look first to see if this has been asked.)
    – C. Tewalt
    Feb 24, 2016 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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