Can't release layer lock on geodatabase

388
10
12-17-2019 02:32 PM
Highlighted
New Contributor III

I'm creating a new layer in a map using LayerFactory.Instance.CreateFeatureLayer with an existing layer file previously created with ArcGIS 10.5.1 (i.e., .lyr, .lyrx).  Once this new layer is created, since I know it's data link is broken I change it's data source to a different data source that contains the appropriate data.  This all works fine.  The problem is that when I change the layer's data source, it puts a lock on the entire geodatabase containing the data and now I can't write anything else to the geodatabase.  Even if I close the map containing the layer, the lock remains until I close Pro. Does anyone have any ideas how to release the lock?  Any help would be greatly appreciated.

Here's my code:

Layer newlayer = LayerFactory.Instance.CreateFeatureLayer(symbologyUri, MyMap, LayerPosition.AddToTop);

CIMStandardDataConnection newDataConnection = new CIMStandardDataConnection()
{
WorkspaceConnectionString = workspaceConnectionStringForNewData,
WorkspaceFactory = WorkspaceFactory.FileGDB,
Dataset = datasetName,
DatasetType = esriDatasetType.esriDTFeatureClass
};

newlayer.SetDataConnection(newDataConnection);  //This is where the lock occurs

Tags (1)
10 Replies
Highlighted
Regular Contributor

Hi Karen,

Few lines were In ArcGIS Pro sample with SetDataConnection (after SetDataConnection call):


                //Bug #2, we manually invalidate the cache
                newlayer.ClearDisplayCache();

We use them in workspace loading tool which loads all feature classes with predefined lyr files and have no problems with database locking. 

I hope it will help.

Reply
0 Kudos
Highlighted
New Contributor III

Thanks so much for the tip!  That still didn't fix the issue, but hopefully it's a step in the right direction.

Reply
0 Kudos
Highlighted
Regular Contributor

Hi Karen, 

I add some parts of my code. One  with new connection and next one with layer adding:

        public static Task ChangeFeatureLayerDataConnectionAsync(FeatureLayer featureLayer, string catalogPath)
        {
            return QueuedTask.Run(() => {
                CIMDataConnection currentDataConnection = featureLayer.GetDataConnection();
                string connection = System.IO.Path.GetDirectoryName(catalogPath);
                string suffix = System.IO.Path.GetExtension(connection).ToLower();
                WorkspaceFactory wf = WorkspaceFactory.FileGDB;
                if (suffix == ".sde")
                {
                    wf = WorkspaceFactory.SDE;
                }
                string dataset = System.IO.Path.GetFileName(catalogPath);
                var dbGdbConnection = new FileGeodatabaseConnectionPath(new Uri(connection, UriKind.Absolute));
                // provide a replace data connection method
                CIMStandardDataConnection updatedDataConnection = new CIMStandardDataConnection()
                {
                    WorkspaceConnectionString = new Geodatabase(dbGdbConnection).GetConnectionString(),
                    WorkspaceFactory = wf,
                    Dataset = dataset,
                    DatasetType = esriDatasetType.esriDTFeatureClass
                };
                featureLayer.SetDataConnection(updatedDataConnection);
                //Bug #2, we manually invalidate the cache
                featureLayer.ClearDisplayCache();
            });
        }
FetureLayer featLayer = (FeatureLayer)LayerFactory.Instance.CreateLayer(new Uri(sLyrPath), map);
ChangeFeatureLayerDataConnectionAsync(featLayer, sDatabase + "\\" + sTableName);
If it will not change your geodatabase locking status, so the problem is in writing to database.
Good luck.
Reply
0 Kudos
Highlighted
New Contributor III

Thanks for the additional info, but I realized that the problem is some change that ESRI has made to how layers in the maps interact with their data sources.  I have some other similar code that worked previously (in July) that doesn't work now and I haven't changed anything in the code, but there have been Arc Pro updates since then.  For any regular Arc Pro code everything works fine, but I have some Gdal code behind the scenes that writes to a geodatabase that is the data source for a layer that is already in the map, and now that code can't get access to the geodatabase because of a schema lock.  This didn't happen before.  So I think I need to submit a bug report.

Highlighted
Occasional Contributor

I had a similar issue.  Rather than wait for ESRI to fix/pay attention, I completely externalized my process in Python using arcpy.  

Reply
0 Kudos
Highlighted
New Contributor III

I submitted a bug report, so we'll see what happens - hope springs eternal .  I went back to earlier versions of Pro, and I found that the problem started in v2.3.2.  In earlier versions our code worked fine.  In the release notes for v2.3.2, one of the bugs that is shown as fixed is: 

BUG-000119207   Adding geodatabase data from a folder connection to a map disables schema locking. 

I'm wondering if "fixing" that bug caused other schema lock problems.

Highlighted
Occasional Contributor

Yes.  That bug is the same trail I went down.  I had a working tool, and was broken after 2.3.2.--schema lock will not release until Pro Application is closed.  Without any API resources to reevaluate, refresh, or force schema locks; I had to work outside the box.  Sad to hear I'm not the only one.

Reply
0 Kudos
Highlighted
New Contributor III

Maybe if enough people report the issue they'll do something about it. This is going to be a big headache to work around.

Reply
0 Kudos
Highlighted
Regular Contributor

Hi Karen.

I am using ArcGIS Pro 2.4.3 and code I copied earlier works for me with all versions from 2.0.

Maybe your file geodatabase has some special components such as geometry network, topology, relationship classes or etc.?

My file geodatabase contains only feature datasets, feature classes and tables.

Reply
0 Kudos