Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
This is happening on Android only... It looks like close is assuming we are in a transaction even if we're not... We're not seeing this on iOS ...
You can see this happening in the notepad sample app here:
This code will generate the error:
var conn = GetConnection();
The following will not generate an error:
var conn = GetConnection();
The error message is visible in Application Output:
[SQLiteLog] (1) statement aborts at 2: [ROLLBACK] cannot rollback - no transaction is active
The implementation of GetConnection is from the sample app:
private static SqliteConnection GetConnection ()
var dbPath = Path.Combine (Environment.GetFolderPath (Environment.SpecialFolder.Personal), db_file);
bool exists = File.Exists (dbPath);
var conn = new SqliteConnection ("Data Source=" + dbPath); // ";Version=3;Pooling=True;Max Pool Size=100;");
return new SqliteConnection(conn);
I am able to replicate this issue on following build:
XS 4.2.3 (build 29)
Refer Screen shot: http://screencast.com/t/o8ydOtXKFa3Y
Does this issue still persist in XA 4.12, thank you.
Hi, we are experiencing exact same as comment 1.
Xamarin.Android version 4.10.01073.
Android OS: 4.1.2
Device: Samsung GT-I9100 (S2)
Seems to have no negative effect, but makes "noise" in logs
There are two possible reasons for this error to occur. First, and the most probable one, is that more than one thread opens the connection to the sqlite database at the same time - SQLite is NOT thread safe. Second is that the database is open in auto-commit mode (the default) and another thread disables that mode (e.g. by calling connection.BeginTransaction ()). Either issue should be handled in the same fashion - by making sure only one thread at a time is using connection to an SQLite database. The database should always be closed after all the queries are performed, keeping the connection open is not a good idea.
The error itself comes from the native sqlite library and it is possible that Android on device ships a different version of the library than the one in iPhone or emulator which would explain why the error doesn't occur in the latter two instances.
I don't see anything we can fix here, unfortunately, therefore I'm going to close this bug as invalid with the recommendation above as the suggested course of action.
I've been getting this error since I started using Xamarin. It doesn't seem to cause any real problem.
However it is definitely not just due to a threading issue. My application doesn't spawn ANY threads, and I have centralized all DB queries through a single method that opens a connection, reads the database, closes the reader, and disposes the connection before returning. The database is never accessed from any other location in the program.
Yet still the error occurs- and it occurs on the conn.Dispose() line. Every single time without exception.
Android API level 16...
@Tyson it might be a bug in the particular version of sqlite native library shipped with Android. Since it has no adverse effects, however, I don't think we can spend more time investigating the issue, sorry about that. Also, threading issues sometimes come up in unexpected locations. Even though your main app might not spawn threads your code may be still called on a different thread (e.g. as a result of async/await or from a timer).