Wie entfernen Sie eine Schema-Sperre für eine DBF-Datei, auf die mit ArcObjects zugegriffen wird?

Question

Ich erstelle ein benutzerdefiniertes Geoverarbeitungswerkzeug für ArcGIS Desktop/Server. Während der Toolausführung erstelle ich eine dbf-Datei und greife mit einem Cursor auf deren Inhalt zu. Die Sperre für diese Datei bleibt bestehen, nachdem das Tool ausgeführt wurde und kann nur durch einen Neustart von ArcMap/ArcCatalog entfernt werden. Gibt es eine programmatische Methode, um die Schemasperre zu entfernen?

Ich habe Zeile für Zeile in den Code unten getreten. Beim Erstellen des ITable ArcObject wird eine Sperrdatei mit der Endung ".sr.lock" erstellt, und beim Erstellen des ICursor-Objekts wird eine Sperrdatei mit der Endung ".rd.lock" im selben Verzeichnis wie die dbf-Datei erstellt. Ohne die ReleaseComObject-Methode unten zu verwenden, bleiben beide Dateien bestehen. Ich kann die zweite Sperrdatei vom Cursor entfernen, aber nicht die, die der Tabelle zugeordnet ist. Selbst wenn ich die dbf-Datei lösche, bleiben die Sperrdateien erhalten und das übergeordnete Verzeichnis kann erst gelöscht werden, wenn ArcMap/ArcCatalog geschlossen wird.

Es gibt Code here, der auf eine Lösung hinweist, aber es gibt Elemente dieses Codes, die fehlen.

public Dictionary<Int32, Dictionary<Int32,Double>> GetTabulatedAreaDict() 
    { 
     IGPUtilities3 gpUtil = new GPUtilitiesClass(); 
     Geoprocessor gp = new Geoprocessor(); 

     //Tabulate Area 
     string tableName = "lcAreaByRru.dbf"; 
     string tablePath = this.tempDirPath + "\\" + tableName; 
     TabulateArea tabulateArea = new TabulateArea(); 
     tabulateArea.in_zone_data = this.rruPath; 
     tabulateArea.zone_field = "VALUE"; 
     tabulateArea.in_class_data = this.rasterValue.GetAsText(); 
     tabulateArea.class_field = "VALUE"; 
     tabulateArea.out_table = tablePath; 
     gp.Execute(tabulateArea, null); 

     // Extract information from table 
     IWorkspaceFactory wsf = new ShapefileWorkspaceFactoryClass(); 
     IWorkspace ws = wsf.OpenFromFile(this.tempDirPath, 0); 
     IFeatureWorkspace fws = (IFeatureWorkspace)ws; 
     ITable taTable = fws.OpenTable(tableName);// Creates .sr.lock file 
     //ITable taTable = gpUtil.OpenTableFromString(tablePath); // Creates .sr.lock file 
     ICursor tableRows = taTable.Search(null, false); // Creates .rd.lock file 
     IRow tableRow = tableRows.NextRow(); 
     this.tabulatedAreaDict = new Dictionary<Int32, Dictionary<Int32, Double>>(); 
     while (tableRow != null) 
     { 
      Int32 id = (Int32)tableRow.get_Value(1); // Feature ID 
      Dictionary<Int32, Double> valueAreaDict = new Dictionary<Int32, Double>(); 
      for (int i = 2; i < tableRow.Fields.FieldCount; i++) 
      { 
       int key = int.Parse(tableRow.Fields.get_Field(i).Name.Split('_')[1]); 
       double value = (double)tableRow.get_Value(i); 
       valueAreaDict.Add(key, value); 
      } 
      this.tabulatedAreaDict.Add(id, valueAreaDict); 
      tableRow = tableRows.NextRow(); 
     } 

     System.Runtime.InteropServices.Marshal.ReleaseComObject(tableRows); //Removes .rd.lock file 
     System.Runtime.InteropServices.Marshal.ReleaseComObject(taTable); // Does not remove .sr.lock file 

     return this.tabulatedAreaDict; 
    } 

Update:

fand ich, dass der dbf nicht verschlossen war, aber es gab Streu Lock-Dateien mit der DBF verbunden. Während ArcCatalog noch lief, konnte ich die Tabelle löschen, aber den Ordner mit dem DBF konnte ich nicht löschen. Das Löschen des übergeordneten Verzeichnisses ist bei Verwendung der ArcCatalog-GUI oder von Windows Explorer fehlgeschlagen. Ich konnte den Ordner mithilfe des Geoverarbeitungswerkzeugs Delete_management löschen.

Ich hatte überlegt, auf den DBF mit einer Nicht-ArcObjects-Methode zuzugreifen, aber mir wurde klar, dass ich später mit Feature-Classes und Geodatabases auf dieses Problem stoßen würde. Daher war es am besten, ArcObjects weiterhin zu verwenden.

Um dieses Problem besser zu beheben, beabsichtige ich, die Tabelle im Arbeitsbereich "scratch" zu erstellen (Systemtemp, wenn nicht angegeben) und dann die Datei an das richtige Ziel zu verschieben, wenn ich den Zugriff beendet habe.

Answer 1

Der Code, den Sie gepostet haben, sieht nicht sehr anders aus als das, was ich normalerweise tue, aber vielleicht könnten Sie versuchen, die Workspace Factory und den Geoprozessor auf eine globalere Ebene zu ziehen, statt sie bei jedem Methodenaufruf instanziieren. Ich erinnere mich daran, dass ich mit dem Geoprozessor einige Locking-Probleme hatte, daher versuche ich, es nicht zu verwenden und direkt mit arcobjects zu arbeiten, wo es möglich ist.

Sie können diese Frage besser unter gis.stackexchange.com stellen. Ich kenne mindestens einen ArcObjects-Guru, der diesen Ort besucht.