Private static void SqLiteConnectionOnChanged(object sender, ConnectionEventArgs connectionEventArgs) SQLiteConnection.Changed += SqLiteConnectionOnChanged Private static readonly List OpenCommands = new List()
#Disconnect from sql db sqlite code#
I've been testing the below code and not seen any file lock issues after a few thousand tests: public static class ClearSQLiteCommandConnectionHelper This seems to be enough to release the file lock. My solution was to ensure the Connection property is set to Null when the connection closes on these SQLiteCommands. I tried disposing these but Entity Framework would then throw an exception during the next DbContext read - it seems EF sometimes still uses them after connection closed. I've been investigating and it seems to be that some SQLiteCommands that EF creates aren't disposed and still have their Connection property set to the closed connection. I've been having the same problem with EF and .įor me I found SQLiteConnection.ClearAllPools() and GC.Collect() would reduce how often the file locking would happen but it would still occasionally happen (Around 1% of the time). SQLiteConnection connection = new SQLiteConnection("Data Source=" + filename + " Version=3 ") The solution is to force a GC after your call to SQLiteConnection.Close() and before your call to File.Delete().
Any volunteers are welcome to do so, unfortunately I am out of time to do so before next year. Since SQLiteConnectionHandle overrides the CriticalHandle.ReleaseHandle() function to call sqlite3_close_interop() (through another function) this does not close the database.įrom my point of view this is a very bad way to do things since the programmer is not actually certain when the database gets closed, but that is the way it has been done so I guess we have to live with it for now, or commit a few changes to. This is done through a call to SQLiteConnectionHandle.Dispose(), however this doesn't actually release the pointer until the CLR's Garbage Collector performs some garbage collection. What happens when you call SQLiteConnection.Close() is that (along with a number of checks and other things) the SQLiteConnectionHandle that points to the SQLite database instance is disposed.
I just ended up throwing an exception when you attempted to delete a SQLite DB using my library.Īnyway, this afternoon I was looking through it all again and figured I would try and find out why it was doing that once and for all, so here is what I've found so far. Throw new IOException("Unable to close file" + filename) Įncountered the same problem a while ago while writing a DB abstraction layer for C# and I never actually got around to finding out what the issue was. GC.Collect() // yes, really release the dbĬatch (IOException e) // delete only throws this on locking Is there anything else I can check? Is there a way to get a list of any open commands or transactions? I saw a two year old bug just like this but the changelog says it's fixed. It does not show my program releasing the db file after the close(). ProcMon shows my program and my antivirus looking at the database file. The sql commands between open and close are just selects.
So I'm fairly sure it's not an open transaction. I have transaction code but it doesn't run at all before the Close() call. I've re-tried the Delete() in the debugger after a few minutes, so it's not a timing issue. The code is just myconnection.Close() Īnd the Delete throws an exception that the file is still in use. I'm having a problem closing my database before an attempt to delete the file.
0 kommentar(er)
