This project is inactive. We recommend using one of the following supported alternatives:
(Note to Faithlife developers: This package should continue to be used in Faithlife applications; the above notice is for external developers who find this project.)
This is an independent implementation of the core of ADO.NET: IDbConnection, IDbCommand, IDbDataReader, IDbTransaction (plus a few helpers) — enough types to let you create and query SQLite databases from managed code, including support for libraries such as Dapper.
It supports the following platforms: .NET Framework 4.7.2., .NET Standard 2.0, Xamarin.iOS, MonoAndroid.
- Lightweight
- Only the core of ADO.NET is implemented, not EF or Designer types.
- The official System.Data.SQLite is over 300KB; this library is under 50KB.
- High performance
- This library assumes that the caller will use
IDisposableproperly, so it avoids adding finalizers to clean up incorrect usage. - No static constructors (e.g.,
SQLiteFunction) that reflect over all loaded assemblies.
- Cross-platform support
- Works on desktop and mobile devices
- Tested
- This implementation has been shipping in Logos 6 and installed on tens of thousands of client machines. The developers track and fix crashes reported via Raygun.
DbDataReader.ReadAsync(CancellationToken)is overridden to support cancellation from another thread (viasqlite3_interrupt).- Added
SQLiteConnection.StatementCompletedto return the results ofsqlite3_profile.
This library is generally compatible with the official System.Data.SQLite API, but a few changes were made where necessary:
- SQLiteConnectionStringBuilder does not support all the official connection string properties.
- SQLiteDataReader performs fewer implicit conversions.
- Not all SQL type aliases (
text,int,blob, etc.) are supported.
This wrapper is managed-only; you still need a copy of the native SQLite library. A recent copy is provided in the lib folder (for the unit tests).
This library implements all the *Async methods of DbCommand, etc. However, because SQLite itself performs
synchronous I/O (and it would be extremely difficult to make it truly async), they don't actually have an async
implementation, but will run synchronously. (Using Task.Run in the implementation is a bad idea;
see also here and here.)
If you need to perform database work off the UI thread, use Task.Run in the UI code to execute a series of
SQLite calls on a background thread.
The *Async methods do support cancellation, though. If you pass in a CancellationToken, the methods will
still run synchronously, but you can interrupt them (even if they're in a long-running loop in SQLite's native code)
by cancelling the cancellation token from another thread. (For example, you can cancel DB work that's happening
on a threadpool thread when a user clicks a "Cancel" button in the UI.)