System.Data.SQLite

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?

mistachkin added on 2011-10-21 10:41:20 UTC:
Could you provide some C# code that demonstrates this issue?

anonymous added on 2011-10-21 13:21:00 UTC:
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.

mistachkin added on 2011-10-22 00:30:21 UTC:
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.

anonymous added on 2011-10-22 16:33:42 UTC:
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?

mistachkin added on 2011-11-06 21:10:11 UTC:
This ticket is pending additional information by the original reporter.

anonymous added on 2011-11-10 21:49:06 UTC:
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.

anonymous added on 2011-11-13 02:21:38 UTC:
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.

mistachkin added on 2011-11-13 08:05:38 UTC:
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.

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

mistachkin added on 2011-11-13 21:30:24 UTC:
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: tkt-e30b820248.eagle

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

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

anonymous added on 2011-11-14 11:56:41 UTC:
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?

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

anonymous added on 2011-11-16 01:10:13 UTC:
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

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

anonymous added on 2011-11-16 20:38:19 UTC:
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?

mistachkin added on 2011-11-17 00:48:58 UTC:
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:

ZIP of latest trunk

anonymous added on 2011-11-17 11:33:56 UTC:
I compiled the latest version, but I still see those trace messages.

Can you confirm they are absolutely harmless? Because we're delaying the shipment of the next version of our software on this, untill we know that it cannot introduce leaks or other problems.

mistachkin added on 2011-11-17 21:04:34 UTC:
Yes, the messages are harmless; however, I would really like to figure out what sequence of steps is required to make them appear. So far, I have had no luck in reproducing the issue here locally. I've attempted to create a test case based on the sample code snippet you provided; however, it always works without any of the trace messages you are referring to.

anonymous added on 2011-11-18 17:55:34 UTC:
Using the latest trunk, I get

SQLite error (21): misuse at line 110832 of [a499ae3835]

Even on simply calling Connection.Open(), that should be easier to reproduce.

mistachkin added on 2011-11-18 18:39:33 UTC:

That message *is* harmless. It's part of a new check performed during initialization of the SQLiteLog class. Please ignore it.

mistachkin added on 2011-11-18 18:43:37 UTC:

Do you still see the *other* messages with the latest trunk code?

mistachkin added on 2011-11-23 02:46:38 UTC:
If there is no further response to issue prior to Friday, the next release will be published on schedule.

anonymous added on 2011-11-27 14:49:23 UTC:
I already reported that I still see the same messages in trunk? I will compare the code of your test-case to mine, to see what are the differences, but at first sight they look very similar.

anonymous added on 2011-12-13 08:06:52 UTC:
i see a lot: SQLite error (21): misuse at line 110832 of [a499ae3835] =>

using(SQLiteConnection cn = new SQLiteConnection()) { cn.ConnectionString = ConnectionString; cn.Open(); { if(!string.IsNullOrEmpty(attachSqlQuery)) { using(DbCommand com = cn.CreateCommand()) { com.CommandText = attachSqlQuery; int x = com.ExecuteNonQuery(); //Debug.WriteLine("Attach: " + x); } }

using(DbCommand com = cn.CreateCommand()) { com.CommandText = string.Format(finnalSqlSelect, pos.X, pos.Y, zoom, type);

using(DbDataReader rd = com.ExecuteReader(System.Data.CommandBehavior.SequentialAccess)) { if(rd.Read()) { long length = rd.GetBytes(0, 0, null, 0, 0); byte[] tile = new byte[length]; rd.GetBytes(0, 0, tile, 0, tile.Length); { if(GMapProvider.TileImageProxy != null) { ret = GMapProvider.TileImageProxy.FromArray(tile); } } tile = null; } rd.Close(); } }

if(!string.IsNullOrEmpty(detachSqlQuery)) { using(DbCommand com = cn.CreateCommand()) { com.CommandText = detachSqlQuery; int x = com.ExecuteNonQuery(); //Debug.WriteLine("Detach: " + x); } } } cn.Close(); }

mistachkin added on 2011-12-15 05:59:31 UTC:
The message "SQLite error (21): misuse at line 110832 of [a499ae3835]" is harmless no matter how many times it occurs.

mistachkin added on 2011-12-15 06:00:03 UTC:
My question was are you seeing any of the *other* log messages still?

anonymous added on 2011-12-16 20:59:34 UTC:
Even if the message is harmless I'd rather it not occur. It's junking up my trace logs and makes it more annoying to look at output since it's always scrolling down for the new messages.

mistachkin added on 2011-12-17 01:02:42 UTC:
Ok, the superfluous log messages have been eliminated by check-in [c3b4597979]. Please let me know if you see any other error messages.

mistachkin added on 2012-01-21 04:39:01 UTC:
This may be fixed by check-in [419bfbd2ee]. Please re-open if that is not the case.