I'm using System.Data.SQLite provider in an ASP.NET application (framework 4.0). The issue I'm running into is that when I INSERT something in a table in the SQLite database, the database gets locked and the lock isn't being released even after the connection is disposed.
When trying to access the file, the error is: "The process cannot access the file 'catalog.sqlite' because it is being used by another process."
My code is pretty straightforward, I open the connection, read some data from a SQLServer database, insert that data into SQLite (through SQLiteDataAdapter) and then close the connection and dispose everything just to be on the safe side. But still, I get that error when I try to zip the file after it's being populated with the data.
I've read all kind of suggestions here on StackOverflow but none of them has helped solving the problem (turning off the antivirus, changing the transaction model, waiting a few seconds before zipping up the file, wrapping all the insert calls into a transaction, etc.. but none has helped solving this issue.
Maybe there's something specific to ASP.NET (multithreading being the issue? Even though I'm testing it on a development machine where there's only one call to that function and no concurrency?)
As a side note, I tried avoiding DataTable and SQLiteDataAdapter and using only SQLiteCommand directly and that way it works a charm. Of course I can keep building my queries as strings instead of using the data adapters, but I kind of find it a bit awkward when there's a framework built to do that.
If you leave it open, it stays open until it goes out of scope and garbage collected. At that point it might be safely closed (and I believe sqlite3 does that). But better to be safe than sorry. Close your connections when you will no longer use them.
close( conn ) closes the SQLite connection by using the MATLAB® interface to SQLite. The SQLite connection object remains open until you close it using the close function. Always close this object when you finish using it.
OperationalError: database is locked errors indicate that your application is experiencing more concurrency than sqlite can handle in default configuration. This error means that one thread or process has an exclusive lock on the database connection and another thread timed out waiting for the lock the be released.
I had the same problem using the datasets/tableadapters generated with the designer shipped with System.Data.Sqlite.dll
version 1.0.82.0 -- after closing the connection we were unable to read the database file using System.IO.FileStream
. I was disposing correctly both connection and tableadapters and I was not using connection pooling.
According to my first searches (for example this and this thread) that seemed a problem in the library itself -- either objects not correctly released and/or pooling issues (which I don't use).
After reading your question I tried to replicate the problem using only SQLiteCommand objects and I found that the problem arises when you don't dispose them. Update 2012-11-27 19:37 UTC: this is further confirmed by this ticket for System.Data.SQLite, in which a developer explains that "all SQLiteCommand and SQLiteDataReader objects associated with the connection [should be] properly disposed".
I then turned back on the generated TableAdapters and I saw that there was no implementation of the Dispose
method -- so in fact the created commands were not disposed. I implemented it, taking care of disposing all the commands, and I have got no problem.
Here's the code in C#, hope this helps. Please note that the code is converted from the original in Visual Basic, so expect some conversion errors.
//In Table Adapter protected override void Dispose(bool disposing) { base.Dispose(disposing); Common.DisposeTableAdapter(disposing, _adapter, _commandCollection); } public static class Common { /// <summary> /// Disposes a TableAdapter generated by SQLite Designer /// </summary> /// <param name="disposing"></param> /// <param name="adapter"></param> /// <param name="commandCollection"></param> /// <remarks>You must dispose all the command, /// otherwise the file remains locked and cannot be accessed /// (for example, for reading or deletion)</remarks> public static void DisposeTableAdapter( bool disposing, System.Data.SQLite.SQLiteDataAdapter adapter, IEnumerable<System.Data.SQLite.SQLiteCommand> commandCollection) { if (disposing) { DisposeSQLiteTableAdapter(adapter); foreach (object currentCommand_loopVariable in commandCollection) { currentCommand = currentCommand_loopVariable; currentCommand.Dispose(); } } } public static void DisposeSQLiteTableAdapter( System.Data.SQLite.SQLiteDataAdapter adapter) { if (adapter != null) { DisposeSQLiteTableAdapterCommands(adapter); adapter.Dispose(); } } public static void DisposeSQLiteTableAdapterCommands( System.Data.SQLite.SQLiteDataAdapter adapter) { foreach (object currentCommand_loopVariable in { adapter.UpdateCommand, adapter.InsertCommand, adapter.DeleteCommand, adapter.SelectCommand}) { currentCommand = currentCommand_loopVariable; if (currentCommand != null) { currentCommand.Dispose(); } } } }
Update 2013-07-05 17:36 UTC gorogm's answer highlights two important things:
according to the changelog on the official site of System.Data.SQLite, starting from version 1.0.84.0 the above code should not be needed, since the library takes care of this. I haven't tested this, but in the worst case you only need this snippet:
//In Table Adapter protected override void Dispose(bool disposing) { base.Dispose(disposing); this.Adapter.Dispose(); }
about the implementation of the Dispose
call of the TableAdapter
: it is is better to put this in a partial class, so that a dataset regeneration does not affected this code (and any additional code you may need to add).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With