FreeWriteLock() not removing lock on file geodatabase

2797
3
Jump to solution
06-09-2016 10:38 AM
JeniferCochran
New Contributor II

I am trying to work on making bulk inserts and deletes but I am having trouble releasing the write lock on the table.  I made a small sample project with only one insert to test the lock and the lock remains even after the table calls FreeWriteLock.  The lock is only removed when the Geodatabase object is closed or disposed of.  I want the lock to be removed when table calls FreeWriteLock.

Using File Geodatabase API 1.4

Here is a sample of my code:

public void InsertRow()

       {

           using (Geodatabase geodatabase = Geodatabase.Open(DestinationDBPath))

           {

               using (Table table = geodatabase.OpenTable("Points"))

               {

                   table.LoadOnlyMode(true);

                   table.SetWriteLock();

                   using (Row row = table.CreateRowObject())

                   {

                       table.Insert(row);

                   }

                   table.LoadOnlyMode(false);

                   table.FreeWriteLock(); //Lock still remains after this call...why??

               }

           }

       }

1 Solution

Accepted Solutions
LanceShipman
Regular Contributor

I've reproduced this and added it as BUG-000097116.

View solution in original post

3 Replies
LanceShipman
Regular Contributor

I've reproduced this and added it as BUG-000097116.

View solution in original post

JeniferCochran
New Contributor II

Thank you for the response.  I have a few follow up questions.

  • Is the only workaround to Close the Geodatabase? or Dispose of it?
    • If so what are the performance impacts for both closing and disposing a Geodatabase?
  • Does this bug also exist in File Geodatabase 1.3 API? (I noticed it on my end, but would like to confirm with you)
Reply
0 Kudos
LanceShipman
Regular Contributor

The performance impact of closing and disposing of the geodatabase is limited. The 1.3 version of the software has the same issue. We are currently  investigating the problem and will post the results of our investigation.