System.Data.SQLite

When I call .Close() on the database connection, i see these errors:

SQLite error (21): API called with finalized prepared statement
SQLite error (21): misuse at line 61617 of [3e0da808d2]
SQLite error (21): API called with finalized prepared statement
SQLite error (21): misuse at line 61617 of [3e0da808d2]
SQLite error (21): API called with finalized prepared statement
SQLite error (21): misuse at line 61617 of [3e0da808d2]
SQLite error (21): API called with finalized prepared statement
SQLite error (21): misuse at line 61617 of [3e0da808d2]
SQLite error (21): API called with finalized prepared statement
SQLite error (21): misuse at line 61617 of [3e0da808d2]

Can I safely ignore them or what do they mean?

<hr /><i>mistachkin added on 2011-10-21 10:41:20 UTC:</i><br />
Could you provide some C# code that demonstrates this issue?


<hr /><i>anonymous added on 2011-10-21 13:21:00 UTC:</i><br />
I can see if I can prepare a test-case for you, but my code is very straight-forward. I create a transaction, create a dbcommand, dispose the dbcommand, commit the transaction, dispose the transaction.

Do you have any idea what kind of problems can give these messages? I did not see them with the dll of PHX Software, and my code did not change.

<hr /><i>mistachkin added on 2011-10-22 00:30:21 UTC:</i><br />
Since I have not been able to reproduce the problem with any of the existing test code, it would be useful to have any additional information you could provide.

<hr /><i>anonymous added on 2011-10-22 16:33:42 UTC:</i><br />
I just see the above lines in the output window of Visual Studio, there is no exception raised, so the existing test-code will never find this error.

I tried to debug it a little today, and whenever my code did some commits with parametrized inserts (.CreateParameter, .Parameters.Add, etc) I always see these messages upon .Close() of the db connection.

So I think the parameters are already garbage collected by the .Net runtime, and the library is trying to dispose them for the second time?

<hr /><i>mistachkin added on 2011-11-06 21:10:11 UTC:</i><br />
This ticket is pending additional information by the original reporter.

<hr /><i>anonymous added on 2011-11-10 21:49:06 UTC:</i><br />
I think I found out the cause, i was doing:

- Dispose DbCommand object
- Commit Transaction object 
- Dispose Transaction object

When I change the order into:

- Commit Transaction object 
- Dispose Transaction object
- Dispose DbCommand object

I don't see any error messages.

<hr /><i>anonymous added on 2011-11-13 02:21:38 UTC:</i><br />
I don't think this ticket should be closed. It's perfectly legal to dispose a DbCommand before committing the transaction?

Also, I found that I can reproduce the issue without transactions at all. When I open the database, do a single call to ExecuteReader(), and close the database, I see the same message if the DbCommand is already disposed or garbage collected.

I will try to find some time to create some example code that reproduces the issue. 

<hr /><i>mistachkin added on 2011-11-13 08:05:38 UTC:</i><br />
The messages you are seeing are generated when the connection is closed and are harmless.  However, if the SQLiteDataReader object associated with the SQLiteCommand object is explicitly disposed prior to the connection being closed (or disposed), you should not see these messages.


<hr /><i>anonymous added on 2011-11-13 13:55:43 UTC:</i><br />
If you are sure that these messages are harmless (no memory leaks or data loss), then this ticket can be closed.

<hr /><i>mistachkin added on 2011-11-13 21:30:24 UTC:</i><br />
I've been attempting to reproduce this issue here, see check-in [68d2140bad].  Is this approximately what you are doing?

Here is a link to the latest version of the test case I am working on for this issue: <a href="/index.html/artifact?ci=tip&filename=Tests/tkt-e30b820248.eagle">tkt-e30b820248.eagle</a>

You'll notice some C# code embedded in the test script, this is what I would like your opinion on.


<hr /><i>mistachkin added on 2011-11-13 21:52:18 UTC:</i><br />
This ticket has been promoted to a blocker for the next release (77).

<hr /><i>anonymous added on 2011-11-14 11:56:41 UTC:</i><br />
The test doesnt need any transactions, I can reproduce with something like this:

class SqlDb
{
private DbConnection Con;

void Open
{
    Con = Fact.CreateConnection();
    Con.Open();
}

DbDatareader GetReader(string sCommand)
{
    DbCommand Com = Con.CreateCommand();
    Com.CommandText = sCommand;
    return Com.ExecuteReader();
}

void Close()
{
    Con.Close();
    Con.Dispose();  
}


And the code that triggers the issue does this:


void Example()
{
   
   DbDatareader Read = SqlDb.GetReader(query)

   [WORK]


   Read.Close()
   SqlDb.Close()

}



So what I think what happens is that the original DbCommand is already disposed, since GetReader() only returns the DbDatareader, not the original command. Then when the database is closed, it cannot find the reference to DbCommand anymore? 

<hr /><i>mistachkin added on 2011-11-14 23:50:33 UTC:</i><br />
Are you using the SQLite.Interop.dll or a standard sqlite3.dll (either downloaded or compiled from sources)?


<hr /><i>anonymous added on 2011-11-16 01:10:13 UTC:</i><br />
I'm using Sqlite.Interop.dll, but I have the same error when using the Mixed-Mode assembly, so it's unrelated. I did not try with sqlite3.dll

<hr /><i>mistachkin added on 2011-11-16 03:17:24 UTC:</i><br />
Could you please try to compile the latest code on trunk and see if the issue still appears?

<hr /><i>anonymous added on 2011-11-16 20:38:19 UTC:</i><br />
I never understood how I can download the source code through Fossil? The normal SQLite Fossil repository has options to download zips of changesets, but here I never see that option?

<hr /><i>mistachkin added on 2011-11-17 00:48:58 UTC:</i><br />
When logged in as 'anonymous' you should be able to download a ZIP archive of any check-in in the source tree.  For example, this link should work:

<a href="/index.html/zip/System.Data.SQLite-trunk.zip?name=trunk">ZIP of latest trunk</a>