From: Lassi Kortela <xxxxxx@lassi.io>
Date: Thursday, September 12, 2019 4:32 AM

>>> I don't know anything about ODBC
>>
>> I dunno, from what I've seen it looks overengineered enterprise
>> bullshit, and old-fashioned as well
>
>You may be right. Here's the current/upcoming C API:
><https://github.com/microsoft/ODBC-Specification/tree/master/Windows/inc>.
>It doesn't seem terrible by any means, but it's a C API and there's
>quite a lot of stuff.

Worse, it's a stab at defining a 4.0 version of ODBC, and there's not
a been change of any substance in the repo since May 2018.  The part
you linked to?  Not in 3 years.

It's also useful to note that Microsoft has had at least 3 different
efforts in this niche.  Contrary to my previous memory, I'm now pretty
sure the intense OLTP work I did with non-mainframe DB2 UDB was
through OLE DB and COM (https://en.wikipedia.org/wiki/OLE_DB), which
per Wikipedia they were more interested in in the mid-1990s than ODBC.
And were planning on dropping support of this year for SQL Server,
but changed their mind in 2017.

Since the 1990s, at the same conceptual level, ADO.NET data providers
are their new hotness, a part of their CLR (Common Language Runtime,
i.e. what C# runs on top of).

All that said, the fate of ODBC is out of their hands, with two
independent but reported to be compatible ODBC Driver Managers and at
least 3 companies providing ODBC drivers for costs that are modest
enough for companies.  But that's unacceptable *to base* our database
API efforts on.  Better to use JDBC to support "second class"
databases beyond PostgreSQL, SQLite, and should their be a 3rd?

I'll bring up first and second class support for databases and what
should be in which in a future posting if no one runs with it now.

- Harold