>ODBC offers the maximum portability for applications. That's assuming
>you want to eventually port to other OSes (e.g. Linux or Mac). ADO ties
>you to Windows. Supposedly ADO is easier to use, but I've got ODBC
>wrappers that hide the ugly side of ODBC quite nicely so the difference
>(from my perspective) is one of portability, not performance or ease-of-use.
We have done the same kind of thing. Our ODBC library has very high as
well as very low level calls so we can access any DBMS with an ODBC
driver with about the same level of abstraction as the BDE, but the low
level calls give us the same level of control as writing raw ODBC access
code.
We have found the performance of ODBC drivers to be as fast as any
other kind of access for the main DBMS platforms we use (MS SQL Server,
MS Access, PostgreSQL, and MySQL). If you use ADO to access
a DBMS via an ODBC driver, it is obvious that the performance has to
be worse than accessing directly via ODBC. Years ago, ODBC had a
bad rep for performance primarily because most of the drivers were
2 tier drivers. Meaning the ODBC driver simply turned around and made
calls to the "native" interface. These days nearly all the drivers are
single tier drivers, meaning they access the backend just as efficiently
as the "native" interface. So, if you use ADO to access an ODBC
backend, you will end up in the same situation the relatively slow
ODBC drivers were in years ago.
There is another consideration besides cross-platform development.
ODBC is based on an industry standard. ODBC 3.0 is a superset of
both the ISO/IEC and X/Open CLI (Call-Level Interface) standards.
Since X/Open CLI is an open standard, we are confident that the
library we have put a lot of work into will work in the future and on
other platforms.
Glenn Lawler
www.incodesystems.com
.