See here for documentation: https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/odbc-api-reference
There seems to be an (automated?) verification program for ODBC from Microsoft: https://docs.microsoft.com/en-us/sql/odbc/odbc-test
Maybe this can be used as a basis: http://www.ch-werner.de/sqliteodbc/
the odbc branch contains a first iteration of this using sqlite's odbc driver
Closing for now, will reopen when there is serious interest.
I would +1 this. It would be an interesting hook-in for SAS + Stata users especially, maybe even Matlab. These are common in the academic community at least.
Of course, one workflow could just be to do your analysis in DuckDB, then write to parquet, but these platforms don't have native Parquet readers. SAS users need to use Spark to convert at the moment. Stata has a parquet reader for Linux shoehorning Arrow bindings. Matlab has native support I believe for Parquet, but could also benefit from being able to call queries WITHIN matlab. One could also write to .csv, but this is the problem I guess we're all hoping to avoid.
Actually, upon second thought: is it possible just to use the JDBC connector for DuckDB across platforms? I think that would solve it. For large record imports, is JDBC faster? MAybe this would be better w/o much extra effort.
@hannesmuehleisen +1 here, too. Having a native ODBC driver for DuckDB would be my dream scenario and would add significant value in being able to build a custom connector for DirectQuery models on top of DuckDB databases in Power BI (would make for some really awesome modeling/analytical capabilities). I already have one for SQLite, but as you would know, this does not scale well with larger datasets. Right now, this is not possible without some JDBC to ODBC bridge, which is not easy to configure.
+1
+1 Having the ability to work with zip, gzip, and Stata will be hugely useful