|
To change values and add new values to a dbf-file, I connect to the dbf and use the ITable interface to make the edits. At the end I release the COM-objects of the table and the workspace. But when I try to open the changed file, it says the file is read-only. Did I forget to release something else? Or is there another reason for the read-only status? Thanks and regards Fab |
|||||
|
|
As to my knowledge and personal experience, this is a general issue when opening files in ArcMap/ArcCatalog or by means of ArcObjects. The lock on those files doesn't get released when they are no longer used in the application. Only closing all ArcGIS applications solves that problem. That behavior is widely known and it's frustrating. |
||||
|
|
|
In my case, I found that the dbf was not locked, but there were stray lock files associated with the dbf. While ArcCatalog was still running, I was able to delete the table, but I was not able to delete the folder containing the dbf. Deletion of the parent directory failed when using the ArcCatalog GUI or Windows Explorer. I was able to delete the folder using the Delete_management geoprocessing tool. I had considered accessing the dbf using a non-ArcObjects method, but I realized I would probably run into this problem later with feature classes and geodatabases, so it was best to continue using ArcObjects. To better manage this issue, I intend to create the table in the scratch workspace (system temp if unspecified) then move the file to the correct destination when I'm finished accessing it. You might want to try this code: I found that it did remove one of the two lock files associated with the dbf. The first reference below has a long discussion on the ReleaseComObject method and recommends its use on geodatabase cursors. References: EDN: How to release COM references gis.stackexchange: How do I remove schema locks from a file geodatabase in java? Stackoverflow.com: How do you remove a schema lock on a dbf file accessed using arcobjects? |
||||
|
|
