|Title:||Connection Close does not immediately release the file lock|
|Last Modified:||2012-12-04 08:43:38|
|Version Found In:||22.214.171.124|
I create a sqlite database to hold filtered data from a bigger sql-server database. In my code i have a simple mechanism which opens a sqlite database connection, create the relevant tables and insert the data previously read from the sql-server tables. After the insert is done i immediately close the connection to the sqlite database. After the close/dispose is called i then create a zip archive containing the sqlite db. After that i want to immediately delete the sqlite db because it's no longer needed but i get always the exception "The process cannot access the file ... because it is being used by another process." After some research on the internet i found a possible solution on stackoverflow: http://stackoverflow.com/questions/8511901/system-data-sqlite-close-not-releasing-database-file I tried that solution and it works if i do a sleep between GC.Collect() and the File.Delete() call. But i think thats not a safe solution. I suggest the SQLiteConnection should provide a way to immediately release the file handle. For my program to work i cannot wait a infinite time to get the database files cleaned up. <hr /><i>mistachkin added on 2012-11-23 22:22:30 UTC:</i><br /> I am not able to reproduce the behavior you describe. In fact, the test suite specifically checks that it can delete a database file immediately after closing it. The key point here is making sure that *all* SQLiteCommand and SQLiteDataReader objects associated with the connection are properly disposed, typically prior to closing the connection. That being said, if you have some C# example code that properly disposes its System.Data.SQLite objects and demonstrates the issue you describe, it would help greatly in tracking down the issue, should there be one.
anonymous added on 2012-12-04 07:32:45:
Something had gone wrong with your ticket system, i already added an reply a week ago. Okay again: The ticket can be closed i found out that we had an extension method in which a data reader was used but not disposed properly so the "leak" was there. After fixing that the close was immediately. Thanks for the quick response to the ticket and furthermore it's a good project keep on going!
mistachkin (claiming to be firstname.lastname@example.org) added on 2012-12-04 08:43:38:
Thanks for the reply, closing ticket.