System.Data.SQLite Close() not releasing database file

Question

I'm having a problem closing my database before an attempt to delete the file. The code is just

 myconnection.Close();    
 File.Delete(filename);

And the Delete throws an exception that the file is still in use. I've re-tried the Delete() in the debugger after a few minutes, so it's not a timing issue.

I have transaction code but it doesn't run at all before the Close() call. So I'm fairly sure it's not an open transaction. The sql commands between open and close are just selects.

ProcMon shows my program and my antivirus looking at the database file. It does not show my program releasing the db file after the close().

Visual Studio 2010, C#, System.Data.SQLite version 1.0.77.0, Win7

I saw a two year old bug just like this but the changelog says it's fixed.

Is there anything else I can check? Is there a way to get a list of any open commands or transactions?

---

New, working code:

 db.Close();
 GC.Collect();   // yes, really release the db

 bool worked = false;
 int tries = 1;
 while ((tries < 4) && (!worked))
 {
    try
    {
       Thread.Sleep(tries * 100);
       File.Delete(filename);
       worked = true;
    }
    catch (IOException e)   // delete only throws this on locking
    {
       tries++;
    }
 }
 if (!worked)
    throw new IOException("Unable to close file" + filename);

Casimir

Did you try: myconnection.Close(); myconnection.Dispose(); ? – Burbot

When using sqlite-net, you can use SQLiteAsyncConnection.ResetPool(), see this issue for details. – Tissue

Answer 1

Encountered 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. I just ended up throwing an exception when you attempted to delete a SQLite DB using my library.

Anyway, 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.

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. 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. Since SQLiteConnectionHandle overrides the CriticalHandle.ReleaseHandle() function to call sqlite3_close_interop() (through another function) this does not close the database.

From 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 System.Data.SQLite. Any volunteers are welcome to do so, unfortunately I am out of time to do so before next year.

TL;DR The solution is to force a GC after your call to SQLiteConnection.Close() and before your call to File.Delete().

Here is the sample code:

string filename = "testFile.db";
SQLiteConnection connection = new SQLiteConnection("Data Source=" + filename + ";Version=3;");
connection.Close();
GC.Collect();
GC.WaitForPendingFinalizers();
File.Delete(filename);

Good luck with it, and I hope it helps

Meroblastic

Yes! Thank you! It looks like the GC might need a little bit to get its work done. – Casimir

You might also want to look at C#SQLite, I've just moved all my code over to using it. Of course, if you are running something performance critical then C is probably faster than C#, but I am a fan of managed code... – Meroblastic

I know this is old, but thanks for saving me some pain. This bug also affects the Windows Mobile / Compact Framework build of SQLite. – Bandolier

Great work! Solved my problem immediately. In 11 years of C# development I never had the need to use GC.Collect: Now this is the first example I'm forced to do so. – Commodious

GC.Collect(); works, but System.Data.SQLite.SQLiteConnection.ClearAllPools(); deals with the issue using the library's API. – Brewton

Also note if you have a reader open you need to close it and you can also skip the GC.Collect() option if you call Dispose on the connection and all command calls. – Cerda

Ran across this today. Unfortunately, it is still an issue with the current version of System.Data.SQLite. Note: calling ClearAllPools does not appear to make a difference, but the GC hack does the trick. – Dallis

This literally saved my life! Unfortunately the ClearAllPools() didn't worked for me. So I used the GC one :) – Thorncombe

This didn't work for me, the file was still closed. ClearAllPools worked (but for some reason, not ClearPool...) – Tunicle

the GC stuff solve my problem. It is the first time me hearing and using this. Thanks. – Episcopacy

I spent about a week trying to figure this out. Thanks! – Lousy

Answer 2

Just GC.Collect() didn't work for me.

I had to add GC.WaitForPendingFinalizers() after GC.Collect() in order to proceed with the file deletion.

Dicho

This is not that surprising, GC.Collect() just starts a garbage collection which is asynchronous so to make sure all has been cleaned up you have to wait for it explicitly. – Humanoid

I experienced the same, had to add the GC.WaitForPendingFinalizers(). This was in 1.0.103 – Memling

Answer 3

The following worked for me:

MySQLiteConnection.Close();
SQLite.SQLiteConnection.ClearAllPools()

More info: Connections are pooled by SQLite in order to improve performance.It means when you call Close method on a connection object, connection to database may still be alive (in the background) so that next Open method become faster.When you known that you don't want a new connection anymore, calling ClearAllPools closes all the connections which are alive in the background and file handle(s?) to the db file get released.Then db file may get removed, deleted or used by another process.

Chafin

Could you please add explanation to why this is good solution to the problem. – Wrench

You can also use SQLiteConnectionPool.Shared.Reset(). This will close all open the connections. In particular, this is a solution if you use SQLiteAsyncConnection that does not have a Close() method. – Firman

Unfortunately, SQLiteConnectionPool is internal and thus can't be used (without reflection). – Charged

ClearAllPools worked for me when waiting for finalizers didn't. Thank you. – Rainout

Answer 4

Had a similar issue, though the garbage collector solution didn't fix it.

Found disposing of SQLiteCommand and SQLiteDataReader objects after use saved me using the garbage collector at all.

SQLiteCommand command = new SQLiteCommand(sql, db);
command.ExecuteNonQuery();
command.Dispose();

Antevert

Exactly. Ensure you dispose EVERY SQLiteCommand even if you recycle a SQLiteCommand variable later on. – Assurance

This worked for me. I also made sure to dispose of any transactions. – Hewett

Great! You saved me quite a bit of time. It fixed the error when I added command.Dispose(); to every SQLiteCommand that was executed. – Citronella

Also, make sure you release (i.e. .Dispose()) other objects like SQLiteTransaction, if you have any. – Citronella

Answer 5

In my case I was creating SQLiteCommand objects without explicitly disposing them.

var command = connection.CreateCommand();
command.CommandText = commandText;
value = command.ExecuteScalar();

I wrapped my command in a using statement and it fixed my issue.

static public class SqliteExtensions
{
    public static object ExecuteScalar(this SQLiteConnection connection, string commandText)
    {
        using (var command = connection.CreateCommand())
        {
            command.CommandText = commandText;
            return command.ExecuteScalar();
        }
    }
}

The using statement ensures that Dispose is called even if an exception occurs.

Then it's a lot easier to execute commands as well.

value = connection.ExecuteScalar(commandText)
// Command object created and disposed

Filter

Answer 6

I was having a similar problem, I've tried the solution with GC.Collect but, as noted, it can take a long time before the file becomes not locked.

I've found an alternative solution that involves the disposal of the underlying SQLiteCommands in the TableAdapters, see this answer for additional information.

Corkage

you were right! In some cases simple 'GC.Collect' worked for me, In others i had to dispose any SqliteCommands associated with the connection before calling GC.Collect or else it won't work! – Ozone

Calling Dispose on the SQLiteCommand worked for me. As an aside comment - if you are calling GC.Collect you are doing something wrong. – Dearly

@NathanAdams when working with EntityFramework there is not a single command object you ever can dispose. So either the EntityFramework itself or the SQLite for EF wrapper is doing somethign wrong, too. – Touchhole

Your answer should be the correct one. Thanks a lot. – Maretz

Answer 7

I've been having the same problem with EF and System.Data.Sqlite.

For 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).

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 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.

My solution was to ensure the Connection property is set to Null when the connection closes on these SQLiteCommands. This seems to be enough to release the file lock. I've been testing the below code and not seen any file lock issues after a few thousand tests:

public static class ClearSQLiteCommandConnectionHelper
{
    private static readonly List<SQLiteCommand> OpenCommands = new List<SQLiteCommand>();

    public static void Initialise()
    {
        SQLiteConnection.Changed += SqLiteConnectionOnChanged;
    }

    private static void SqLiteConnectionOnChanged(object sender, ConnectionEventArgs connectionEventArgs)
    {
        if (connectionEventArgs.EventType == SQLiteConnectionEventType.NewCommand && connectionEventArgs.Command is SQLiteCommand)
        {
            OpenCommands.Add((SQLiteCommand)connectionEventArgs.Command);
        }
        else if (connectionEventArgs.EventType == SQLiteConnectionEventType.DisposingCommand && connectionEventArgs.Command is SQLiteCommand)
        {
            OpenCommands.Remove((SQLiteCommand)connectionEventArgs.Command);
        }

        if (connectionEventArgs.EventType == SQLiteConnectionEventType.Closed)
        {
            var commands = OpenCommands.ToList();
            foreach (var cmd in commands)
            {
                if (cmd.Connection == null)
                {
                    OpenCommands.Remove(cmd);
                }
                else if (cmd.Connection.State == ConnectionState.Closed)
                {
                    cmd.Connection = null;
                    OpenCommands.Remove(cmd);
                }
            }
        }
    }
}

To use just call ClearSQLiteCommandConnectionHelper.Initialise(); at the start of application load. This will then keep a list of active commands and will set their Connection to Null when they point to a connection that is closed.

Solfeggio

I had to also set the connection to null in the DisposingCommand part of this, or I would occasionally get ObjectDisposedExceptions. – Jesse

This is an underrated answer in my opinion. It solved my the cleanup issues that I couldn't do myself because of the EF layer. Very happy to use this over that ugly GC hack. Thank you! – Kidskin

If you use this solution in a multithreaded environment, the OpenCommands List should be [ThreadStatic]. – Stoller

Answer 8

The reason for this seems to be a feature called "Pooling". Appending "Pooling=false" to the connection string causes the DB-File to be released with "connection.Close()".

See the FAQ on connection pooling here: https://www.devart.com/dotconnect/sqlite/docs/FAQ.html#q54

Jews

Answer 9

Try this... this one tries all the above codes... worked for me

    Reader.Close()
    connection.Close()
    GC.Collect()
    GC.WaitForPendingFinalizers()
    command.Dispose()
    SQLite.SQLiteConnection.ClearAllPools()

Hope that helps

Reinert

WaitForPendingFinalizers made all the difference for me – Keratitis

Answer 10

Use GC.WaitForPendingFinalizers()

Example:

Con.Close();  
GC.Collect();`
GC.WaitForPendingFinalizers();
File.Delete(Environment.CurrentDirectory + "\\DATABASENAME.DB");

Balbriggan

Answer 11

Best answer that worked for me.

dbConnection.Close();
System.Data.SQLite.SQLiteConnection.ClearAllPools();

GC.Collect();
GC.WaitForPendingFinalizers();

File.Delete(Environment.CurrentDirectory + "\\DATABASENAME.DB");

Woo

Answer 12

I believe the call to SQLite.SQLiteConnection.ClearAllPools() is the cleanest solution. As far as I know it is not proper to manually call GC.Collect() in the WPF environment. Although, I did not notice the problem until I have upgraded to System.Data.SQLite 1.0.99.0 in 3/2016

Babette

Answer 13

Had a similar problem. Calling Garbage Collector didn't help me. LAter I found a way to solve the problem

Author also wrote that he did SELECT queries to that database before trying to delete it. I have the same situation.

I have the following code:

SQLiteConnection bc;
string sql;
var cmd = new SQLiteCommand(sql, bc);
SQLiteDataReader reader = cmd.ExecuteReader();
reader.Read();
reader.Close(); // when I added that string, the problem became solved.

Also, I don't need to close database connection and to call Garbage Collector. All I had to do is to close reader which was created while executing SELECT query

Consult

Answer 14

I was struggling with the similar problem. Shame on me... I finally realized that Reader was not closed. For some reason I was thinking that the Reader will be closed when corresponding connection is closed. Obviously, GC.Collect() didn't work for me.
Wrapping the Reader with "using: statement is also a good idea. Here is a quick test code.

static void Main(string[] args)
{
    try
    {
        var dbPath = "myTestDb.db";
        ExecuteTestCommand(dbPath);
        File.Delete(dbPath);
        Console.WriteLine("DB removed");
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message);
    }
    Console.Read();
}

private static void ExecuteTestCommand(string dbPath)
{
    using (var connection = new SQLiteConnection("Data Source=" + dbPath + ";"))
    {
        using (var command = connection.CreateCommand())
        {
            command.CommandText = "PRAGMA integrity_check";
            connection.Open();
            var reader = command.ExecuteReader();
            if (reader.Read())
                Console.WriteLine(reader.GetString(0));

            //without next line database file will remain locked
            reader.Close();
        }
    }   
}

Elbertelberta

Answer 15

Maybe you don't need to deal with GC at all. Please, check if all sqlite3_prepare is finalized.

For each sqlite3_prepare, you need a correspondent sqlite3_finalize.

If you don't finalize correctly, sqlite3_close will not close the connection.

Albaugh

Answer 16

This works for me but i noticed sometimes journal files -wal -shm are not deleted when the process is closed. If you want SQLite to remove -wal -shm files when all connection are close the last connection closed MUST BE non-readonly. Hope this will help someone.

Tetrasyllable

More specifically it seems that the combo of the open flags ReadOnly | SharedCache will keep the -wal & -shm files around. ReadOnly by itself will let it close completely (at least in my case). Which in retrospect makes sense since the SQL driver wouldn't know if we're done sharing the cache or not. – Sipper

Edit: Gah, actually now it also depends on if an Async connection was used at any point on the same DB... if it was then just having the last connection be ReadOnly (with or w/out SharedCache) will still leave the extra files... and the ResetPool() thing doesn't help either. – Sipper

Answer 17

I was using SQLite 1.0.101.0 with EF6 and having trouble with the file being locked after all connections and entities disposed.

This got worse with updates from the EF keeping the database locked after they had completed. GC.Collect() was the only workaround that helped and I was beginning to despair.

In desperation, I tried Oliver Wickenden's ClearSQLiteCommandConnectionHelper (see his answer of 8 July). Fantastic. All locking problems gone! Thanks Oliver.

Stun

I think this should be a comment instead of an answer – Lyndialyndon

Kevin, I agree, but I was not allowed to comment because I need 50 reputation (apparently). – Stun

Answer 18

Waiting for Garbage Collector may not release the database all time and that happened to me. When some type of Exception occurs in SQLite database for example trying to insert a row with existing value for PrimaryKey it will hold the database file until you dispose it. Following code catches SQLite exception and cancels problematic command.

SQLiteCommand insertCommand = connection.CreateCommand();
try {
    // some insert parameters
    insertCommand.ExecuteNonQuery();
} catch (SQLiteException exception) {
    insertCommand.Cancel();
    insertCommand.Dispose();
}

If you not handle problematic commands' exceptions than Garbage Collector cannot do anything about them because there are some unhandled exceptions about these commands so they are not garbage. This handling method worked well for me with waiting for garbage collector.

Wade