For any real world application, I would 1. Not want to be more than two versions behind the <i>current</i> SQLite release. 2. Want to have an environment for testing the next or work-in-progress version of SQLite. I have no control over what version of SQLite is available in System.Data.SqLite or Microsoft.Data.Sqlite. Being in control of what version to use can make a world of difference. 1. An enhancement such as <b>.read '| </b> currently in the pipeline can save hours of work. 2. So would an enhancement to <b> ALTER TABLE </b> that permits a column to be dropped. Using the ODBC connection, I can choose which version of SQLite I use. However some useful features are unavailable: a. <b style="color:blue"> SQLiteConfigDbOpsEnum</b> is unavailable - I will need to construct/build this. b. <b style="color:blue">SetConfigurationOption</b> is unavailable - I am not sure how I would implement something like >SetConfigurationOption(SQLiteConfigDbOpsEnum.SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION, true); c. <b style="color:blue">BindFunction</b> is unavailable; this would be a very valuable feature as it enables any method in a DLL (including ones I write myself) to be bound and used inside SQL statements. d. <b style="color:blue">EnableExtensions</b> is unavailable (for loading such like mmod_spatialite - but I have a workaround. The file <i style="color:red">sqlite3.def</i> simply lists the names of the exported functions. It does <u>not</u> provide the methods' signatures which must be known to be able to build <i style="color:red">SQLite.Interop.dll</i> I believe. The choice is not <i>easy!</i>