SDE copy feature to FGDB, subsequent Near tool execution fails with schema lock error

[MatthewBarlow]

I am attempting to run the following code (more or less, as I have simplified it for display here):

arcpy.env.workspace = ws
arcpy.env.overwriteOutput = True

arcpy.MakeFeatureLayer_management(sde_fc, gdb_fc)
arcpy.SelectLayerByLocation_management(gdb_fc, 'WITHIN_A_DISTANCE', gdb_asset_name, "1000")

matchcount = int(arcpy.GetCount_management(gdb_fc).getOutput(0))
if matchcount <> 0:
     arcpy.CopyFeatures_management(gdb_fc, ws + "\\" + gdb_fc)
     
            
arcpy.Near_analysis(gdb_fc, gdb_asset_name, "#", "#", "ANGLE")

           
It functions as expected when copying the selected features from a file geodatabase or shapefiles. However, when copying from SDE, it fails and returns:

ERROR 000464: Cannot get exclusive schema lock.  Either being edited or in use by another application.
Lock request conflicts with an established lock

To complicate matters, it isn't consistent with all SDE databases. On some it functions correctly, but not on the one I need to point to. Could this be a lock carrying over from SDE in the FGDB?

[JakeSkinner]

Hi Matt,

Do you have any ArcGIS Server services accessing the SDE feature classes? 

Also, you can check the user that is causing the lock by making a connection to the geodatabase as an Administrator > right-click on the geodatabase > Administration > Administer Geodatabase.

[ATTACH=CONFIG]31230[/ATTACH]

[MatthewBarlow]

Hi Jake,

Yes, the feature class from which the selection set is derived does have ArcGIS Server services pointed at it. I didn't think this would affect the features that are copied from SDE, however, once they are committed to the FGDB. The feature classes in the FGDB are where the Near_analysis is being run.

I've verified the user of the lock is the user that I am making the connection to SDE with. It is also the user that everyone in the organisation uses to access SDE (database authentication).

Thanks very much for your response,
Matt

Hi Matt,

Do you have any ArcGIS Server services accessing the SDE feature classes? 

Also, you can check the user that is causing the lock by making a connection to the geodatabase as an Administrator > right-click on the geodatabase > Administration > Administer Geodatabase.

[ATTACH=CONFIG]31230[/ATTACH]

[JakeSkinner]

I believe the problem is when you run the Near analysis.  You are still running this on the SDE feature class.  Try the following instead:

arcpy.Near_analysis(ws + "\\" + gdb_fc, gdb_asset_name, "#", "#", "ANGLE")

[MatthewBarlow]

I have the selection/copy and Near_analysis in separate functions, so the below is my actual code for the Near_analysis bit:

new_asset = g_asset_name
ws = full_path + "\\" + g_gdb_name

arcpy.env.workspace = ws
arcpy.env.overwriteOutput = True
fcList = arcpy.ListFeatureClasses()
for fc in fcList:
     if fc <> new_asset:
          arcpy.Near_analysis(fc, new_asset, "#", "#", "ANGLE")

Does this look a bit better? My previous code example was pieced together, so apologies for the confusion. And many thanks for your help.

Cheers,
Matt

[JakeSkinner]

Can you post the entire script?  It's tough to troubleshoot without knowing what the variables are.

[MatthewBarlow]

The entire script is quite long and the variables are passed in from a wx dialog, so they aren't expressed in code... The strange behaviour is that the script functions correctly when pointed to a different SDE database or a FGDB that I created with manual exports from SDE. In these case, the Near_analysis performs as expected and populates a column with the angle & distance, which I turn into direction and distance. It is only when pointed at a specific SDE database that it encounters the schema lock. Very frustrating.

[JamesCrandall]

I think what Jake might be getting at is perhaps you are accessing the output FGDB workspace at the same time somewhere else in your code or not releasing a previous reference to it.  I'd think that would cause accessibility issues on subsequent attempts to write to the workspace.

[MatthewBarlow]

I think what Jake might be getting at is perhaps you are accessing the output FGDB workspace at the same time somewhere else in your code or not releasing a previous reference to it.  I'd think that would cause accessibility issues on subsequent attempts to write to the workspace.

Thanks for the reply. However, if I simply change my input source (which is a parameter in an input file) to a different SDE database that has a copy of the data OR an independent FGDB into which I copied the layers I need to access, it works fine. For example, I exported all 54 layers from this particular SDE database to another SDE database, pointed my script at that and it works fine. If my code is locking the FGDB I am writing to, then wouldn't it fail no matter the input source? Besides, my understanding is that it won't lock out subsequent processes within the same instance.