nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can't release layer lock on geodatabase

KarenMeinstein

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

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

KarenMeinstein

I had a Eureka! moment today about this issue while putting together a simple example of the problem for ESRI support. The failure occurs when the gdal code that is accessing the geodatabase is within the QueryTask.Run call where the data in the same geodatabase is accessed (i.g., LayerFactory.Instance.CreateFeatureLayer()). If I move the gdal code outside of the QueryTask.Run, it can access the geodatabase with no problem. This wasn't obvious in my original code because the gdal code was in a method called from within the QueryTask.Run.

So this code doesn't work:

public async Task RunTest()
{
   await QueuedTask.Run(async () =>
   {
      Map testMap = MapFactory.Instance.CreateMap("Test");
      testMap.SetSpatialReference(SpatialReferences.WGS84);

Uri layerUri = new Uri(@C:\Users\kbmeinstein\Desktop\GDBTest\GDBtest.gdb\polygons);

ArcGIS.Desktop.Mapping.Layer newlayer = LayerFactory.Instance.CreateFeatureLayer(layerUri, testMap, LayerPosition.AddToBottom);

await ProApp.Panes.CreateMapPaneAsync(testMap);

Driver fileGDBDriver = OSGeo.OGR.Ogr.GetDriverByName("FileGDB");

//Failure happens here:
DataSource dataSource = fileGDBDriver.Open(@C:\Users\kbmeinstein\Desktop\GDBTest\GDBtest.gdb, 1);
});

}

But this does:

public async Task RunTest()
{
   await QueuedTask.Run(async () =>
   {
      Map testMap = MapFactory.Instance.CreateMap("Test");
      testMap.SetSpatialReference(SpatialReferences.WGS84);

Uri layerUri = new Uri(@C:\Users\kbmeinstein\Desktop\GDBTest\GDBtest.gdb\polygons);

ArcGIS.Desktop.Mapping.Layer newlayer = LayerFactory.Instance.CreateFeatureLayer(layerUri, testMap, LayerPosition.AddToBottom);

await ProApp.Panes.CreateMapPaneAsync(testMap);
});

Driver fileGDBDriver = OSGeo.OGR.Ogr.GetDriverByName("FileGDB");

//This works fine now:
DataSource dataSource = fileGDBDriver.Open(@C:\Users\kbmeinstein\Desktop\GDBTest\GDBtest.gdb, 1);

}

An important thing to note is that in Pro v2.3.1, code like the example above that doesn't work now (i.e., with the gdal within the QueryTask.Run) worked fine, so something definitely changed in v2.3.2. Hopefully they'll fix this, but at least now I have a workaround and hopefully this is helpful to someone else.

KarenMeinstein

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.

GKmieliauskas

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.

KarenMeinstein

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

GKmieliauskas

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.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.