Re: Performance of ODBC vs. other access methods

it  wouldn't surprise me if the underlying driver in all 
cases was an ODBC driver  (one using the ODBC protocol),

No such thing as the "ODBC" protocol. The reason there are ODBC drivers
for each provider is that the ODBC driver converts the ODBC API calls
into the necessary protocols on a provider by provider basis. IIRC,
there was some attempt at standardizing the wire-protocol for data
access so you wouldn't need a custom driver on each machine. The success
of that effort is obvious based on the fact that we're all still using
provider-specific drivers.

Now, if you mean that the .NET or Java driver sits on top of the ODBC
driver, absolutely not. There is a type of JDBC driver that does (type
2???) but no one uses them unless you really have to, and there is a
.NET to ODBC bridge, but again it's not used unless necessary. A type 4
JDBC driver, or a native .NET driver (including IBM's driver) is a
ground-up implementation of a driver. Did the copy/paste some code? I'm
sure, but it's not sitting on top of it.

As for ODBC performance in general, you can't confuse ODBC performance
w/ADO performance, or with the performance of an application that uses
ODBC. I had subsecond response time from ODBC applications in the mid
90s against old B and F class AS/400s with multi-million row tables.
Granted, it was hand-coded c++ directly accessing the ODBC API, but ODBC
itself is quite fast, it's a question of what you do with it.

-Walden