This project makes use of Eagle, provided by Mistachkin Systems.
Extensible Adaptable Generalized Logic Engine
08:43 Closed ticket [3186bfc523]: Connection Close does not immediately release the file lock plus 5 other changes artifact: af97b2779e user: mistachkin
07:32 Ticket [3186bfc523]: 4 changes artifact: f7ffe82b4d user: anonymous
22:22 Pending ticket [3186bfc523]. artifact: cf1c59935e user: mistachkin
08:05 New ticket [3186bfc523]. artifact: c6851c9de2 user: anonymous

Ticket Hash: 3186bfc523ccaba9f3b57bef68ebe22a53163d48
Title: Connection Close does not immediately release the file lock
Status: Closed Type: Incident
Severity: Minor Priority: Low
Subsystem: Integration_Via_PInvoke Resolution: Works_As_Designed
Last Modified: 2012-12-04 08:43:38
Version Found In:
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:

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.

mistachkin added on 2012-11-23 22:22:30 UTC:
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.

User Comments:
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 added on 2012-12-04 08:43:38:
Thanks for the reply, closing ticket.